Subject: Re: [ippm] Call for implementation reports of RFC2678-2681

From: "Henk Uijterwaal (RIPE NCC)" <[email-masked]>
Date: Tue, 27 Jul 2004 13:02:28 +0200 (CEST)

IPPM group,

On Thu, 4 Mar 2004, Henk Uijterwaal (RIPE NCC) wrote:

> Even though the process to move RFC2678 through 2781 from proposed
> standard to standard is likely to be changed in the coming year, the
> chairs would like to start collecting implementation reports for these
> RFCs.
>
> If you have implemented any of
>
>  RFC2678   Connectivity
>  RFC2679   One way delay
>  RFC2680   Packet Loss
>  RFC2681   Round trip Delay
>
> Please provide us with an implementation report.  This report should
> contain (at least):
>
> * Name of implementation
> * Organization that did the implementation
> * Contact details
> * Origin of the code
> * Platform (what it is running on)
> * Metrics implemented
>
> And optionally:
>
> * Features implemented
> * Metrics and features not implemented, and why you did not implement
>   them.
> * Tests done on the implementation such as:
>    - Comparison of metrics with 2+ implementations
>    - Verification of results with passive methods
>    - Error estimation, clock source
>
> Please send reports to the chairs privately,
>
> Matt & Henk

So-far, I have received 1 report, with a promise for a second one.  If you
did implement any of these metrics, please let me know.  If you want to
discuss your report in San Diego next week, we do have time on the agenda.

Henk

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

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
[email-masked] 
https://www1.ietf.org/mailman/listinfo/ippm

---

From: "Henk Uijterwaal (RIPE NCC)" <[email-masked]>
Date: Tue, 27 Jul 2004 13:06:28 +0200 (CEST)

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: [email-masked]
                             URL:   http://www.ripe.net/ttm
                             Phone: +31.20.5354444

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.