RTFM Turnaround Times

• Last RTFM meeting (DC IETF December 99) discussed better ways to recognise send/reply packet pairs, so as to get better Round-trip (Turnaround) Times
• The WG agreed that we should make a (short) list of protocols for which a meter can reliably detectrequest/response pairs. For example:
  • ICMP echo/response
  • DNS (UDP) echo/response
  • SNMP (UDP) request/response
  • TCP SYN/SYN-ACK, data/ACK
• I have implemented packet-pair matching in NeTraMet 44b6; ßThis talk presents some experimental results gathered to date
• All the distributions presented cover 10-minute intervals

Matching UDP Packets

• An IP flow may aggregate many ICMP, UDP or TCP streams
• Each stream maintains a queue on information about observed packets, including
  • Direction (S->D or D->S)
  • Time observed
  • Protocol
  • Information about packet
• Ping, DNS and SNMP have explicit sequence numbers which are
  easy to match, yielding RTTs
• Timed-out request packets (RTT > upper limit of distribution) are counted as 'lost' packets

UDP RTT Measurements

• Above map shows the sites selected for experiments From SDSC
  • Ping and DNS SOA . to E, J, I and M root servers
  • Ping and DNS SOA clear.net.nz to dns1.clear.net.nz
  From Auckland
  • Ping and DNS SOA . to F root server
  • Passive observation of DNS A to F, J, I and M root servers
  • Passive observation of recursive DNS A to dns1.clear and nzix
• Mutually prime intervals were chosen for the test packet streams so as to avoid synchronisation effects
• ToTurnaroundTime distributions were collected every 10 minutes

(Active) DNS RTTs Observed at SDSC

• E and J show U.S. diurnal variation
• M and CLEAR show Asia-Pacific diurnal variation
• I (Stockholm) has much less variation

(Active) J root (NSI) RTT and Loss % from SDSC

(Active) I root (KTH) RTT and Loss % from SDSC

(Active) Auckland DNS RTT and Loss % from SDSC

(Passive) DNS RTTs Observed at Auckland

(Active) F root (Woodside) RTT and Loss % from Auckland

Active and Passive DNS RTTs from Auckland

(Passive) New Zealand DNS RTTs from Auckland

Matching TCP Packets

• TCP queue kept in ascending order of expected Acks
• Can't get RTT for every packet, only those which are ACKed
• Overlapping packets (resent) are counted as lost, but not queued
• This means the first copy of resent packets are used for RTTs, giving a high RTT estimate

Passive TCP RTTs (1..120 ms) from Auckland to dblclick.au (Melbourne)

Passive TCP RTTs (1..120 ms) from Auckland to global-centre (Melbourne)

Comments on TCP RTTs

• SYN/ACK is a good estimate of RTT
• 'Single' data/ACKs are a little higher
• 'In group' data/ACKs are much higher - this seems surprising

TCP Stream Size distributions

• Observed at Auckland gateway for all TCP traffic in and out
• Stream size = difference between first and last SEQ numbers
• Distribution counters are incremented when a flow terminates

TCP Stream Sizes (3.. 1500 Bytes) on Tuesday 21 March

TCP Stream Sizes (1..1500 kB) on Friday 24 March

Conclusion

• DNS RTT for SOA and A from root servers matches well with Ping RTT, Passive DNS A RTTs provide a good overview of network availability
• 'Single' Data/ACK pairs are a fair approximation to RTT for long-running streams
• TCP RTT for SYN/ACK matches well with Ping RTT, Single data/ACK pairs are a good approximation for short-duration streams
• Nearly all the TCP streams to/from Auckland have < 1k bytes in them; most streams will have only one or two packet pairs in them !