The contents of this legacy page are no longer maintained nor supported, and are made available only for historical purposes.

Packet Matching for NeTraMet Distributions

How to do packet matching with NeTraMet, by Nevil Brownlee (The University of Auckland / CAIDA, n.brownlee@auckland.ac.nz). This slide set was presented at the 2000 IETF in Adelaide, Australia.


  1. 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

  2. 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

  3. 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

  4. (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

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


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


  7. (Active) Auckland DNS RTT and Loss % from SDSC


  8. (Passive) DNS RTTs Observed at Auckland


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


  10. Active and Passive DNS RTTs from Auckland


  11. (Passive) New Zealand DNS RTTs from Auckland



  12. 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

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


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


  15. 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

  16. 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

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


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



  19. 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 !

Related Objects

See https://catalog.caida.org/details/software/netramet/ to explore related objects to this document in the CAIDA Resource Catalog.
Published
Last Modified