1 / 8

Measuring Packet Reordering

Measuring Packet Reordering. NETREAD UC Berkeley George Porter Oct 4, 2002. Motivation. Reordering needs to be understood Mismatch between best-effort guarantee of IP and assumptions made by TCP Fast retransmit VoIP apparently not designed to handle reorder, only jitter

kaipo
Download Presentation

Measuring Packet Reordering

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Measuring Packet Reordering NETREAD UC Berkeley George Porter Oct 4, 2002

  2. Motivation • Reordering needs to be understood • Mismatch between best-effort guarantee of IP and assumptions made by TCP • Fast retransmit • VoIP apparently not designed to handle reorder, only jitter • Non idempotent protocols (should those exist?)

  3. Single connection test

  4. Single connection test forward No reorder d2 d2 • Requires 2 samples • Packet loss causes problems • Delayed acks • To solve delayed ack issue, reverse the order. But now you can’t tell forward from reverse path reorder a1 a1 d1 d3 d3 a3 a1 d1 a4 a4 d2 d2 a1 a1 d1 d3 d3 d1 a4 a3 a4 a1 reverse both

  5. Dual connection test • The two connections allow associating acks with data • Packets are acked in order they are received • Can test if diff between IPIDs of acks is consistent with order in which data packets were sent • [example on board]

  6. Problems with dual test • Relies on strictly increasing IPID values (MTU discovery in Linux prevents that) • Load balancers cause problems (separate hosts on the back end) • SYN trick to work around that • Convince load balancers to hash 4-tuple to same host • RST, ACK are used to determine reorder • SYN attack may be inferred

  7. TCP Data transfer test • Only can detect reorder on the reverse path • Requires software on the end host • Not good for testing some web hosts, since you need lots of packets to make these observations, and web traffic might fit into one packet

  8. Test environment • 99.99% success rate on closed environment • Internet wide: • 40% of paths had some reordering • They use confidence intervals and null hypotheses, etc… • Data transfer method may catch only half the reorders

More Related