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 !