Re: [ippm] RIPE NCC's implementation report for RFC2678-2681

["Henk Uijterwaal (RIPE NCC)" <[e-mail]>]

IPPM group,

Here is our (RIPE NCC)'s implementation report for RFC's 2678-2681.
Mainly FYI and to act as a template if you planned to write one yourself.

Henk

- - - - -


General
=======

Name of Implementation:      RIPE NCC Test Traffic Measurements
                             (RIPE NCC TTM or TTM)

Organization:                RIPE NCC

Contact details:             RIPE NCC
                             P.O.Box 10096, 1001 EB Amsterdam, the Netherlands
                             Email: [e-mail]
                             URL:   http://www.ripe.net/ttm
                             Phone: [phone]

Origin of code:              Written from scratch.
                             Uses NTP (RFC1305) and BPF (from LBL)

Platform:                    FreeBSD (versions 2.2.8, 4.5 and higher)

Metrics
=======

RFC2679/Type-P-One-way-Delay
----------------------------

Parameters:                                 Implemented?
 + Src, the IP address of a host            Yes
 + Dst, the IP address of a host            Yes
 + T, a time                                Yes

Units:
 + dT                                       Yes

Methodology:
 + According to section 3.6 of RFC 2679

Comments:
 + UDP packets are being used.
 + No special IP bits are set.

Features included:
 + A bit to record if the src thinks its clock is synchronized or not
   (based on NTP).  Measurements with unsynchronized clocks are not used
   in higher level statistics.
 + A bit to record if the dst thinks its clock is synchronized or not
 + Experimental error estimate for src clock
 + Experimental error estimate for dst clock
 + Experimental error estimate for the measurement
 + Ports used at source and destination

Features not implemented:
 + No special IP bits can be set.

Reporting the metric:
 + Negative delay values are reported.  Small negative values can occur when
   the experimental errors on the clocks are large and the delays are small.
 + Maximum delay is 255 seconds, packets with higher delays are considered lost.
 + Packet size is being reported.
 + All systematic errors are removed from the timestamps before reporting
   the metrics
 + Paths are being determined by running the well-known traceroute tool
   approximately 10 times an hour, with the most recent path reported.

Tests performed:
 + Cross check of measurements against the surveyor implementation
   (Reported at thet IETF44, IPPM WG meeting).
 + Cross check of measurements with passive measurements
   (Reported at PAM2001)

RFC2679/Type-P-One-way-Delay-Poisson-Stream
-------------------------------------------

Parameters:
 +  Src, the IP address of a host                   Yes
 +  Dst, the IP address of a host                   Yes
 +  T0, a time                                      Yes
 +  Tf, a time                                      Yes
 +  lambda, a rate in reciprocal seconds            Yes

Note: Lambda is reported as packets per minute.

Units:
 +  T, a time, and                                                 Yes
 +  dT, either a real number or an undefined number of seconds.    Yes

Report consists of series of measurements for Type-P-One-Way-Delay.

RFC2679/Type-P-One-way-Delay-Median
-----------------------------------
This value is being calculated and reported, for 15 minutes (or longer)
intervals.  15 minutes came from user feedback.

RFC2679/Type-P-One-way-Delay-Minimum
------------------------------------
Not implemented.  We do, however, report the 2.5% and 97.5% of the
distribution for 15 minutes (or longer) intervals.

RFC2680/Type-P-One-way-Packet-Loss
----------------------------------

Metric Parameters:                                  Implemented
 +  Src, the IP address of a host                    Yes
 +  Dst, the IP address of a host                    Yes
 +  T, a time                                        Yes

Metric Units:
 + Type-P-One-way-Packet-Loss                        Yes

Comments:
 + UDP packets are being used.
 + No special IP bits are set.
 + A packet is considered lost if it has not arrived after 255 seconds.  There
   is no distinction between packets that do arrive but take longer than 255
   seconds, or that never arrive at all.
 + The time is the time the packet was sent, rounded to the nearest full second.

Further comments:
This metric has been implemented in combination with RFC2679/Type-P-OWD.
All comments made there apply.

RFC2680/Type-P-One-way-Packet-Loss-Poisson-Stream
-------------------------------------------------
This has been implemented as part of RFC2679/Type-P-OWD-Poisson-Stream.
Results consists of a series of measurements for the One Way Delay, with
values of -1 for packets that were sent but did not arrive.

RFC2680/Type-P-One-way-Packet-Loss-Average
------------------------------------------
This is being calculated for 15 minute (or longer) intervals.

RFC2678 and 2681
----------------
Have not been implemented due to a lack of demand from customers.

------------------------------------------------------------------------------
Henk Uijterwaal                           Email: henk.uijterwaal(at)ripe.net
RIPE Network Coordination Centre          http://www.amsterdamned.org/~henk
P.O.Box 10096          Singel 258         Phone: [phone]
1001 EB Amsterdam      1016 AB Amsterdam  Fax: [phone]
The Netherlands        The Netherlands    Mobile: [phone]
------------------------------------------------------------------------------

Process and Procedure are the last hiding place of people without the wit
and wisdom to do their job properly.                          (David Brent).

_______________________________________________
ippm mailing list
[e-mail] 
https://www1.ietf.org/mailman/listinfo/ippm