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 –Non idempotent protocols (should those exist?)

Single connection test

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 d2 a1 d1 a3d3 a4 d2 a1 d3 a1 d1 a4 d2 a1 d1 a3 d3 a4 d2 a1 d3 a1 d1 a4 No reorder forward reverse both

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]

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

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

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