draft-ietf-ippm-owmetric-as-00.txt   draft-ietf-ippm-owmetric-as-01.txt 
Internet Draft Henk Uijterwaal Internet Draft Henk Uijterwaal
Document: draft-ietf-ippm-owmetric-as-00.txt Merike Kaeo Document: draft-ietf-ippm-owmetric-as-01.txt Merike Kaeo
Expires: December 2002 July 2002 Expires: June 2003 November 2002
One-Way Metric Applicability Statement One-Way Metric Applicability Statement
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. Internet-Drafts are working provisions of Section 10 of RFC2026. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, and documents of the Internet Engineering Task Force (IETF), its areas, and
its working groups. Note that other groups may also distribute working its working groups. Note that other groups may also distribute working
documents as Internet-Drafts. documents as Internet-Drafts.
skipping to change at page 3, line 33 skipping to change at page 3, line 33
than the MTU to avoid effects due to fragmentation and reassembly. than the MTU to avoid effects due to fragmentation and reassembly.
Before running any actual measurements, one should perform tests to see Before running any actual measurements, one should perform tests to see
if delay depends on packet size other than scaling with the packet size. if delay depends on packet size other than scaling with the packet size.
If this appears to be the case, one should try to estimate packet sizes If this appears to be the case, one should try to estimate packet sizes
for "user" data using passive measurements and adjust the packet size for "user" data using passive measurements and adjust the packet size
accordingly, or use a variable packet size according to the distribution accordingly, or use a variable packet size according to the distribution
seen in user data. These tests should be repeated when the path between seen in user data. These tests should be repeated when the path between
source and destination changes. source and destination changes.
Also note that some line card designs have buffer pools of different
sizes. This can lead to loss being different for different packet
sizes.
When packets are sent larger than the minimum size required by the When packets are sent larger than the minimum size required by the
measurement device, the remainder of the packet should be padded with measurement device, the remainder of the packet should be padded with
random bits in order to avoid compression being applied to any random bits in order to avoid compression being applied to any
measurement packets. measurement packets. The algorithm to generate these random bits as
well as any seed values have to be known, in order to be able to fully
understand any remaining issues with compression.
3.3 Timing issues 3.3 Timing issues
The measured metric should report experimental errors on the accuracy of The measured metric should report experimental errors on the accuracy of
the clocks. This has been seen to only be an issue during measurement the clocks. This has been seen to only be an issue during measurement
test start-up. In the case of using NTP, it starts with an estimate and test start-up. In the case of using NTP, it starts with an estimate and
as the clock starts to stabilize it corrects the internal clock of the as the clock starts to stabilize it corrects the internal clock of the
device. In the case of IPDV, there are 2 timestamps and initial errors device.
can be huge.
When the IPDV metric is being measured, one use 4 time-stamps: send and
arrival time of the first packet and, send and arrival time of the
second packet. The difference between these time-stamps will be small.
One should take care that sufficient accuracy for the calculation is
available and check that the experimental error on the overall result is
still small compared to the result.
The clock should be checked for correct performance at regular intervals The clock should be checked for correct performance at regular intervals
and measurements should be discarded when there is a problem. and measurements should be discarded when there is a problem.
One should check if the overall experimental error is small compared to One should check if the overall experimental error is small compared to
the delay before further processing of the data. The errors should be the delay before further processing of the data. The errors should be
recorded so they are available when calculating derived metrics such as recorded so they are available when calculating derived metrics such as
IPDV. IPDV.
3.4 Test duration 3.4 Test duration
The test duration can be infinitely long. There is a preference for The test duration can be infinitely long depending on the metric and
continuous measurements to more easily see traffic variations. This is application. In order to easily see traffic variations, measurements
especially important for performing traffic engineering and/or load should run for a long time but have a limited life-time. The former
balancing. The active measurements should only be started/stopped when requirement makes it easier to use the data for traffic engineering or
adding/removing boxes or when there are networking problems. load balancing.
How to report intermediate results? The latter requirement allows for a easy failure detection: suppose one
is measuring between A and B. At some point in time, B stops receiving
packets. Until the measurement session times out, there is no way to
tell if this is due to full connectivity loss between A and B, or due to
a failure of the device A. When the measurement session ends, one can
attempt to restart it. If one can contact the host at A, one can
conservatively assume that A crashed.
How to report intermediate results while the test is in progress?
3.5. Data volumes 3.5. Data volumes
It is important to ensure that any measurement traffic does not It is important to ensure that any measurement traffic does not
interfere with normal network operations. Initially, one should check interfere with normal network operations. Initially, one should check
if outgoing/incoming data volume for a box is small with respect to link if outgoing/incoming data volume for a box is small with respect to link
capacity of the first few hops to avoid measurements being affected by capacity of the first few hops to avoid measurements being affected by
loaded links. Also, one should check that the machine sending/receiving loaded links. Also, one should check that the machine sending/receiving
the data can cope with the expected offered load. Lastly, make sure that the data can cope with the expected offered load. Lastly, make sure that
the total test traffic volume sent or received by a machine is small the total test traffic volume sent or received by a machine is small
compared to total link capacity, a number of 3% of the total capacity compared to total link capacity, a number of 3% of the total available
seems reasonable. capacity seems reasonable for routine monitoring of the performance of a
link without affecting the performance of that link.
Capacity and reordering measurements that fill a link at (almost) its
maximum line rate should not be used on production networks except
during scheduled maintenance or test periods.
4. Reporting metrics 4. Reporting metrics
4.1. When is a result different? 4.1. When is a result different?
Given 2 sets of measurements, when is set 1 statistically different from Given 2 sets of measurements, when is set 1 statistically different from
set 2? set 2?
When do you have reasonable probability that things have not changed or When do you have reasonable probability that things have not changed or
are OK with your network? This might vary from application to are OK with your network? This might vary from application to
application of the data. application of the data.
4.2. Alarms 4.2. Alarms
>From the previous paragraph, it follows when 2 results are different. From the previous paragraph, it follows when 2 results are different.
This can be used to define thresholds for delay alarms. This can be used to define thresholds for delay alarms.
4.3. Average/Sigma versus 2.5/median/97.5% 4.3. Average/Sigma versus 2.5/median/97.5%
Since Average/Sigma for a one-way delay distribution is not well Since Average/Sigma for a one-way delay distribution is not well
defined, and percentiles are,we should use the latter. defined, and percentiles are,we should use the latter.
If it necessary to use Average/Sigma, then it should be specified how If it necessary to use Average/Sigma, then it should be specified how
losses are treated in the calculation. losses are treated in the calculation.
Question: what about the loss metrics: average/sigma or percentiles.
Question: Larry Dunn suggest filtering theory to get a feeling for
the shape of a curve. Anybody who wants to elaborate?
5.0 Reporting the IPDV metric. 5.0 Reporting the IPDV metric.
Using average/sigma for reporting the IPDV metric does not work: first Using average/sigma for reporting the IPDV metric does not work: first
of all, the average will almost always be close to zero. Then, the of all, the average will almost always be close to zero. Then, the
distribution generally is not Gaussian and the sigma is not well distribution generally is not Gaussian and the sigma is not well defined
defined. for the distributions that are being seen.
Using percentiles suffers from the same problem: the median will almost Using percentiles suffers from the same problem: the median will almost
always be 0, and the 2.5 and 97.5% will be the same. always be 0, and the 2.5 and 97.5% will be the same.
What appears to be working is 2 percentiles, for example 5 and 25%, this What appears to be working is 2 percentiles, for example 5 and 25%, this
gives a reasonable description of the shape of the distribution. gives a reasonable description of the shape of the distribution.
Question: Stas: do you have some better wording?
6.0 Access to the data 6.0 Access to the data
Measurement results comprise of both raw data and derived results. The Measurement results comprise of both raw data and derived results. The
raw data should be kept accessible to allow for historical trend raw data should be kept accessible to allow for historical trend
analysis. analysis.
A minimum set of informative fields to be stored is: A minimum set of informative fields to be stored is:
* IP address of source * IP address of source
* IP address of destination * IP address of destination
* Time the packet was sent (or arrived) * Time the packet was sent (or arrived)
* Delay * Delay
* Experimental error on sending and receiving clock * Experimental error on sending and receiving clock
* Packet Size * Packet Size
* ... * ...
skipping to change at page 6, line 16 skipping to change at page 6, line 45
10. References 10. References
[1] RFC2679 [1] RFC2679
[2] RFC2680 [2] RFC2680
[3] RFC2330 [3] RFC2330
[4] RFC2119 [4] RFC2119
11. Acknowledgments 11. Acknowledgments
Victor Reijs (HEANET) July 9's comments incorporated. Stanislav
Shalunov's comments from July 26 added, Aug 8 added.
12. Authors' Addresses 12. Authors' Addresses
Henk Uijterwaal Henk Uijterwaal
RIPE Network Coordination Centre RIPE Network Coordination Centre
Singel 258 Singel 258
1016 AB Amsterdam 1016 AB Amsterdam
The Netherlands The Netherlands
Phone: +31.20.5354414 Phone: +31.20.5354414
Fax: +31.20.5354445 Fax: +31.20.5354445
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/