Skip to Content
[CAIDA - Center for Applied Internet Data Analysis logo]
Center for Applied Internet Data Analysis > tools : measurement : netramet : packetmatching
Packet Matching for NeTraMet Distributions

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

|   RTFM architecture    Packet Matching    NeTraMet Distribution    DNS Measurement    Changes and Extensions   |
  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 to

      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 (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 !

  Last Modified: Mon Jul-6-2020 22:31:11 UTC
  Page URL: