draft-ietf-ippm-npmps-06.txt   draft-ietf-ippm-npmps-07.txt 
IP Performance Measurement Working Group V.Raisanen IP Performance Measurement Working Group V.Raisanen
Internet Draft Nokia Internet Draft Nokia
Document: <draft-ietf-ippm-npmps-06.txt> G.Grotefeld Document: <draft-ietf-ippm-npmps-07.txt> G.Grotefeld
Category: Informational Motorola Category: Standards Track Motorola
A.Morton A.Morton
AT&T Labs AT&T Labs
Network performance measurement with periodic streams Network performance measurement with periodic streams
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1]. all provisions of Section 10 of RFC2026 [1].
skipping to change at page 2, line 4 skipping to change at line 52
sampling method and sample metric parameters, measurement methods sampling method and sample metric parameters, measurement methods
and errors are discussed. Finally, we give additional information on and errors are discussed. Finally, we give additional information on
periodic measurements including security considerations. periodic measurements including security considerations.
2. Conventions used in this document 2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [2]. document are to be interpreted as described in RFC 2119 [2].
Although RFC 2119 was written with protocols in mind, the key words Although RFC 2119 was written with protocols in mind, the key words
Network performance measurement with periodic streams Feb 2002
are used in this document for similar reasons. They are used to are used in this document for similar reasons. They are used to
ensure the results of measurements from two different ensure the results of measurements from two different
implementations are comparable, and to note instances when an implementations are comparable, and to note instances when an
implementation could perturb the network. implementation could perturb the network.
3. Introduction 3. Introduction
This memo describes a sampling method and performance metrics This memo describes a sampling method and performance metrics
relevant to certain applications of IP networks. The original driver relevant to certain applications of IP networks. The original driver
for this work was Quality of Service of interactive periodic streams for this work was Quality of Service of interactive periodic streams
skipping to change at page 3, line 5 skipping to change at line 104
* An active measurement can be configured to match the * An active measurement can be configured to match the
characteristics of media flows, and simplifies the estimation of characteristics of media flows, and simplifies the estimation of
application performance. application performance.
* Measurements of many network impairments (e.g., delay variation, * Measurements of many network impairments (e.g., delay variation,
consecutive loss, reordering) are sensitive to the sampling consecutive loss, reordering) are sensitive to the sampling
frequency. When the impairments themselves are time-varying (and frequency. When the impairments themselves are time-varying (and
the variations are somewhat rare, yet important), a constant the variations are somewhat rare, yet important), a constant
sampling frequency simplifies analysis. sampling frequency simplifies analysis.
Network performance measurement with periodic streams Feb 2002
* Frequency Domain analysis is simplified when the samples are * Frequency Domain analysis is simplified when the samples are
equally spaced. equally spaced.
Simulation of CBR flows with periodic streams encourages dense Simulation of CBR flows with periodic streams encourages dense
sampling of network performance, since typical multimedia flows have sampling of network performance, since typical multimedia flows have
10 to 100 packets in each second. Dense sampling permits the 10 to 100 packets in each second. Dense sampling permits the
characterization of network phenomena with short duration. characterization of network phenomena with short duration.
4. Periodic Sampling Methodology 4. Periodic Sampling Methodology
The Framework RFC [3] points out the following potential problems The Framework RFC [3] points out the following potential problems
with Periodic Sampling: with Periodic Sampling:
1. The performance sampled may be synchronized with some other 1. The performance sampled may be synchronized with some other
periodic behavior, or the samples may be anticipated and the results periodic behavior, or the samples may be anticipated and the
manipulated. Unpredictable sampling is preferred. results manipulated. Unpredictable sampling is preferred.
2. Active measurements can cause congestion, and periodic sampling 2. Active measurements can cause congestion, and periodic sampling
might drive congestion-aware senders into a synchronized state, might drive congestion-aware senders into a synchronized state,
producing atypical results. producing atypical results.
Poisson sampling produces an unbiased sample for the various IP Poisson sampling produces an unbiased sample for the various IP
performance metrics, yet there are situations where alternative performance metrics, yet there are situations where alternative
sampling methods are advantageous (as discussed under Motivation). sampling methods are advantageous (as discussed under Motivation).
We can prescribe periodic sampling methods that address the problems We can prescribe periodic sampling methods that address the problems
skipping to change at page 3, line 47 skipping to change at line 144
bias of interest. The total traffic generated by this or any bias of interest. The total traffic generated by this or any
sampling method should be limited to avoid adverse affects on non- sampling method should be limited to avoid adverse affects on non-
test traffic (packet size, packet rate, and sample duration and test traffic (packet size, packet rate, and sample duration and
frequency should all be considered). frequency should all be considered).
The configuration parameters of periodic sampling are: The configuration parameters of periodic sampling are:
+ T, the beginning of a time interval where a periodic sample is + T, the beginning of a time interval where a periodic sample is
desired. desired.
+ dT, the duration of the interval for allowed sample start times. + dT, the duration of the interval for allowed sample start times.
+ T0, a time that MUST be selected at random from the interval [T, + T0, a time that MUST be selected at random from the interval
T+dT] to start generating packets and taking measurements. [T, T+dT] to start generating packets and taking measurements.
+ Tf, a time, greater than T0, for stopping generation of packets + Tf, a time, greater than T0, for stopping generation of packets
for a sample (Tf may be relative to T0 if desired). for a sample (Tf may be relative to T0 if desired).
+ incT, the nominal duration of inter-packet interval, first bit to + incT, the nominal duration of inter-packet interval, first bit to
first bit. first bit.
T0 may be drawn from a uniform distribution, or T0 = T + Unif(0,dT). T0 may be drawn from a uniform distribution, or T0 = T + Unif(0,dT).
Other distributions may also be appropriate. Start times in Other distributions may also be appropriate. Start times in
successive time intervals MUST use an independent value drawn from successive time intervals MUST use an independent value drawn from
the distribution. In passive measurement, the arrival of user media the distribution. In passive measurement, the arrival of user media
Network performance measurement with periodic streams Feb 2002
flows may have sufficient randomness, or a randomized start time of flows may have sufficient randomness, or a randomized start time of
the measurement during a flow may be needed to meet this the measurement during a flow may be needed to meet this
requirement. requirement.
When a mix of packet sizes is desired, passive measurements usually When a mix of packet sizes is desired, passive measurements usually
possess the sequence and statistics of sizes in actual use, while possess the sequence and statistics of sizes in actual use, while
active measurements would need to reproduce the intended active measurements would need to reproduce the intended
distribution of sizes. distribution of sizes.
5. Sample metrics for periodic streams 5. Sample metrics for periodic streams
skipping to change at page 5, line 5 skipping to change at line 208
smaller than the maximum or predominant size of packets in the smaller than the maximum or predominant size of packets in the
periodic stream. periodic stream.
A topology where Src and Dst are separate from the measurement A topology where Src and Dst are separate from the measurement
points is assumed. points is assumed.
5.2.2 Parameters collected at the measurement point MP(Src) 5.2.2 Parameters collected at the measurement point MP(Src)
Parameters that each Singleton usually includes: Parameters that each Singleton usually includes:
Network performance measurement with periodic streams Feb 2002
+ Tstamp(Src)[i], for each packet [i], the time of the packet as + Tstamp(Src)[i], for each packet [i], the time of the packet as
measured at MP(Src) measured at MP(Src)
Additional parameters: Additional parameters:
+ PktID(Src) [i], for each packet [i], a unique identification or + PktID(Src) [i], for each packet [i], a unique identification or
sequence number. sequence number.
+ PktSi(Src) [i], for each packet [i], the actual packet size. + PktSi(Src) [i], for each packet [i], the actual packet size.
Some applications may use packets of different sizes, either Some applications may use packets of different sizes, either
because of application requirements or in response to IP because of application requirements or in response to IP
skipping to change at page 6, line 5 skipping to change at line 260
Duplicate: Only the first non-corrupt copy of the packet Duplicate: Only the first non-corrupt copy of the packet
received at Dst should have Delay [i] computed. received at Dst should have Delay [i] computed.
A sample metric for average delay is as follows A sample metric for average delay is as follows
AveDelay = (1/N)Sum(from i=1 to N, Delay[i]) AveDelay = (1/N)Sum(from i=1 to N, Delay[i])
assuming all packets i= 1 though N have valid singletons. assuming all packets i= 1 though N have valid singletons.
A delay variation [5] singleton can also be computed: A delay variation [5] singleton can also be computed:
Network performance measurement with periodic streams Feb 2002
+ IPDV[i], for each packet [i] except the first one, delay + IPDV[i], for each packet [i] except the first one, delay
variation between successive packets would be calculated as variation between successive packets would be calculated as
IPDV[I] = Delay[i] - Delay [i-1] IPDV[I] = Delay[i] - Delay [i-1]
IPDV[i] may be negative, zero, or positive. Delay singletons for IPDV[i] may be negative, zero, or positive. Delay singletons for
packets i and i-1 must be calculable or IPDV[i] is undefined. packets i and i-1 must be calculable or IPDV[i] is undefined.
An example metric for the IPDV sample is the range: An example metric for the IPDV sample is the range:
skipping to change at page 6, line 51 skipping to change at line 304
This sampling methodology is intended to quantify the delays and the This sampling methodology is intended to quantify the delays and the
delay variation as experienced by multimedia streams of an delay variation as experienced by multimedia streams of an
application. Due to the definitions of these metrics, also packet application. Due to the definitions of these metrics, also packet
loss status is recorded. The nominal interval between packets loss status is recorded. The nominal interval between packets
assesses network performance variations on a specific time scale. assesses network performance variations on a specific time scale.
There are a number of factors that should be taken into account when There are a number of factors that should be taken into account when
collecting a sample metric of Type-P-One-way-Delay-Periodic-Stream. collecting a sample metric of Type-P-One-way-Delay-Periodic-Stream.
+ The interval T0 to Tf should be specified to cover a long enough + The interval T0 to Tf should be specified to cover a long enough
time interval to represent a reasonable use of the application under time interval to represent a reasonable use of the application
test, yet not excessively long in the same context(e.g. phone calls under test, yet not excessively long in the same context (e.g.
last longer than 100ms, but less than one week). phone calls last longer than 100ms, but less than one week).
+ The nominal interval between packets (incT) and the packet + The nominal interval between packets (incT) and the packet
size(s) (p(j)) should not define an equivalent bit rate that exceeds size(s) (p(j)) should not define an equivalent bit rate that
the capacity of the egress port of Src, the ingress port of Dst, exceeds the capacity of the egress port of Src, the ingress port
of Dst, or the capacity of the intervening network(s), if known.
Network performance measurement with periodic streams Feb 2002 There may be exceptional cases to test the response of the
application to overload conditions in the transport networks, but
or the capacity of the intervening network(s), if known. There may these cases should be strictly controlled.
be exceptional cases to test the response of the application to
overload conditions in the transport networks, but these cases
should be strictly controlled.
+ Real delay values will be positive. Therefore, it does not make + Real delay values will be positive. Therefore, it does not make
sense to report a negative value as a real delay. However, an sense to report a negative value as a real delay. However, an
individual zero or negative delay value might be useful as part of individual zero or negative delay value might be useful as part
a stream when trying to discover a distribution of the delay errors. of a stream when trying to discover a distribution of the
delay errors.
+ Depending on measurement topology, delay values may be as low as + Depending on measurement topology, delay values may be as low as
100 usec to 10 msec, whereby it may be important for Src and Dst to 100 usec to 10 msec, whereby it may be important for Src and Dst
synchronize very closely. GPS systems afford one way to achieve to synchronize very closely. GPS systems afford one way to
synchronization to within several 10s of usec. Ordinary application achieve synchronization to within several 10s of usec. Ordinary
of NTP may allow synchronization to within several msec, but this application of NTP may allow synchronization to within several
depends on the stability and symmetry of delay properties among the msec, but this depends on the stability and symmetry of delay
NTP agents used, and this delay is what we are trying to measure. properties among the NTP agents used, and this delay is what we
are trying to measure.
+ A given methodology will have to include a way to determine + A given methodology will have to include a way to determine
whether packet was lost or whether delay is merely very large (and whether packet was lost or whether delay is merely very large
the packet is yet to arrive at Dst). The global metric parameter (and the packet is yet to arrive at Dst). The global metric
dTloss defines a time interval such that delays larger than dTloss parameter dTloss defines a time interval such that delays larger
are interpreted as losses. {Comment: For many applications, the than dTloss are interpreted as losses. {Comment: For many
treatment a large delay as infinite/loss will be inconsequential. A applications, the treatment a large delay as infinite/loss will
TCP data packet, for example, that arrives only after several be inconsequential. A TCP data packet, for example, that arrives
multiples of the usual RTT may as well have been lost.} only after several multiples of the usual RTT may as well have
been lost.}
5.5 Additional Methodology Aspects 5.5 Additional Methodology Aspects
As with other Type-P-* metrics, the detailed methodology will depend As with other Type-P-* metrics, the detailed methodology will depend
on the Type-P (e.g., protocol number, UDP/TCP port number, size, on the Type-P (e.g., protocol number, UDP/TCP port number, size,
precedence). precedence).
5.6 Errors and uncertainties 5.6 Errors and uncertainties
The description of any specific measurement method should include an The description of any specific measurement method should include an
skipping to change at page 8, line 5 skipping to change at line 366
uneven process scheduling, possibly due to CPU load. uneven process scheduling, possibly due to CPU load.
+ Errors or uncertainties due to uncertainties in the clocks of the + Errors or uncertainties due to uncertainties in the clocks of the
MP(Src) and MP(Dst) measurement points. MP(Src) and MP(Dst) measurement points.
+ Errors or uncertainties due to the difference between 'wire time' + Errors or uncertainties due to the difference between 'wire time'
and 'host time'. and 'host time'.
5.6.1. Errors or uncertainties related to Clocks 5.6.1. Errors or uncertainties related to Clocks
Network performance measurement with periodic streams Feb 2002
The uncertainty in a measurement of one-way delay is related, in The uncertainty in a measurement of one-way delay is related, in
part, to uncertainties in the clocks of MP(Src) and MP(Dst). In the part, to uncertainties in the clocks of MP(Src) and MP(Dst). In the
following, we refer to the clock used to measure when the packet was following, we refer to the clock used to measure when the packet was
measured at MP(Src) as the MP(Src) clock and we refer to the clock measured at MP(Src) as the MP(Src) clock and we refer to the clock
used to measure when the packet was received at MP(Dst) as the used to measure when the packet was received at MP(Dst) as the
MP(Dst) clock. Alluding to the notions of synchronization, MP(Dst) clock. Alluding to the notions of synchronization,
accuracy, resolution, and skew, we note the following: accuracy, resolution, and skew, we note the following:
+ Any error in the synchronization between the MP(Src) clock and + Any error in the synchronization between the MP(Src) clock and
the MP(Dst) clock will contribute to error in the delay measurement. the MP(Dst) clock will contribute to error in the delay
We say that the MP(Src) clock and the MP(Dst) clock have a measurement. We say that the MP(Src) clock and the MP(Dst) clock
synchronization error of Tsynch if the MP(Src) clock is Tsynch ahead have a synchronization error of Tsynch if the MP(Src) clock is
of the MP(Dst) clock. Thus, if we know the value of Tsynch exactly, Tsynch ahead of the MP(Dst) clock. Thus, if we know the value of
we could correct for clock synchronization by adding Tsynch to the Tsynch exactly, we could correct for clock synchronization by
uncorrected value of Tstamp(Dst)[i] - Tstamp(Src) [i]. adding Tsynch to the uncorrected value of Tstamp(Dst)[i] -
Tstamp(Src) [i].
+ The resolution of a clock adds to uncertainty about any time + The resolution of a clock adds to uncertainty about any time
measured with it. Thus, if the MP(Src) clock has a resolution of measured with it. Thus, if the MP(Src) clock has a resolution of
10 msec, then this adds 10 msec of uncertainty to any time value 10 msec, then this adds 10 msec of uncertainty to any time value
measured with it. We will denote the resolution of the source measured with it. We will denote the resolution of the source
clock and the MP(Dst) clock as ResMP(Src) and ResMP(Dst), clock and the MP(Dst) clock as ResMP(Src) and ResMP(Dst),
respectively. respectively.
+ The skew of a clock is not so much an additional issue as it is a + The skew of a clock is not so much an additional issue as it is a
realization of the fact that Tsynch is itself a function of time. realization of the fact that Tsynch is itself a function of time.
Thus, if we attempt to measure or to bound Tsynch, this needs to Thus, if we attempt to measure or to bound Tsynch, this needs to
be done periodically. Over some periods of time, this function can be done periodically. Over some periods of time, this function
be approximated as a linear function plus some higher order terms; can be approximated as a linear function plus some higher order
in these cases, one option is to use knowledge of the linear terms; in these cases, one option is to use knowledge of the
component to correct the clock. Using this correction, the residual linear component to correct the clock. Using this correction,
Tsynch is made smaller, but remains a source of uncertainty that the residual Tsynch is made smaller, but remains a source of
must be accounted for. We use the function Esynch(t) to denote an uncertainty that must be accounted for. We use the function
upper bound on the uncertainty in synchronization. Thus, Esynch(t) to denote an upper bound on the uncertainty in
|Tsynch(t)| <= Esynch(t). synchronization. Thus, |Tsynch(t)| <= Esynch(t).
Taking these items together, we note that naive computation Taking these items together, we note that naive computation
Tstamp(Dst)[i] - Tstamp(Src) [i] will be off by Tsynch(t) +/- Tstamp(Dst)[i] - Tstamp(Src) [i] will be off by Tsynch(t) +/-
(ResMP(SRc) + ResMP(Dst)). Using the notion of Esynch(t), we note (ResMP(SRc) + ResMP(Dst)). Using the notion of Esynch(t), we note
that these clock-related problems introduce a total uncertainty of that these clock-related problems introduce a total uncertainty of
Esynch(t)+ Rsource + Rdest. This estimate of total clock-related Esynch(t)+ Rsource + Rdest. This estimate of total clock-related
uncertainty should be included in the error/uncertainty analysis of uncertainty should be included in the error/uncertainty analysis of
any measurement implementation. any measurement implementation.
5.6.2. Errors or uncertainties related to Wire-time vs Host-time 5.6.2. Errors or uncertainties related to Wire-time vs Host-time
We would like to measure the time between when a packet is measured We would like to measure the time between when a packet is measured
and time-stamped at MP(Src) and when it arrives and is time-stamped and time-stamped at MP(Src) and when it arrives and is time-stamped
at MP(Dst) and we refer to these as "wire times." If timestamps are at MP(Dst) and we refer to these as "wire times." If timestamps are
applied by software on Src and Dst, however, then this software can applied by software on Src and Dst, however, then this software can
only directly measure the time between when Src generates the packet only directly measure the time between when Src generates the packet
just prior to sending the test packet and when Dst has started to just prior to sending the test packet and when Dst has started to
Network performance measurement with periodic streams Feb 2002
process the packet after having received the test packet, and we process the packet after having received the test packet, and we
refer to these two points as "host times". refer to these two points as "host times".
To the extent that the difference between wire time and host time is To the extent that the difference between wire time and host time is
accurately known, this knowledge can be used to correct for wire accurately known, this knowledge can be used to correct for wire
time measurements and the corrected value more accurately estimates time measurements and the corrected value more accurately estimates
the desired (host time) metric, and visa-versa. the desired (host time) metric, and visa-versa.
To the extent, however, that the difference between wire time and To the extent, however, that the difference between wire time and
host time is uncertain, this uncertainty must be accounted for in an host time is uncertain, this uncertainty must be accounted for in an
skipping to change at page 9, line 55 skipping to change at line 466
at least 95 percent of the time. We call "e" the calibration error at least 95 percent of the time. We call "e" the calibration error
for the measurements. It represents the degree to which the values for the measurements. It represents the degree to which the values
produced by the measurement instrument are repeatable; that is, how produced by the measurement instrument are repeatable; that is, how
closely an actual delay of 30 ms is reported as 30 ms. closely an actual delay of 30 ms is reported as 30 ms.
{Comment: 95 percent was chosen due to reasons discussed in [4], {Comment: 95 percent was chosen due to reasons discussed in [4],
briefly summarized as (1) some confidence level is desirable to be briefly summarized as (1) some confidence level is desirable to be
able to remove outliers, which will be found in measuring any able to remove outliers, which will be found in measuring any
physical property; (2) a particular confidence level should be physical property; (2) a particular confidence level should be
specified so that the results of independent implementations can be specified so that the results of independent implementations can be
compared.} compared.}
From the discussion in the previous two sections, the error in From the discussion in the previous two sections, the error in
measurements could be bounded by determining all the individual measurements could be bounded by determining all the individual
uncertainties, and adding them together to form uncertainties, and adding them together to form
Network performance measurement with periodic streams Feb 2002
Esynch(t) + ResMP(Src) + ResMP(Dst) + Hsource + Hdest. Esynch(t) + ResMP(Src) + ResMP(Dst) + Hsource + Hdest.
However, reasonable bounds on both the clock-related uncertainty However, reasonable bounds on both the clock-related uncertainty
captured by the first three terms and the host-related uncertainty captured by the first three terms and the host-related uncertainty
captured by the last two terms should be possible by careful design captured by the last two terms should be possible by careful design
techniques and calibrating the instruments using a known, isolated, techniques and calibrating the instruments using a known, isolated,
network in a lab. network in a lab.
For example, the clock-related uncertainties are greatly reduced For example, the clock-related uncertainties are greatly reduced
through the use of a GPS time source. The sum of Esynch(t) + through the use of a GPS time source. The sum of Esynch(t) +
skipping to change at page 11, line 5 skipping to change at line 521
example, recording the measurements), all of which may increase the example, recording the measurements), all of which may increase the
random error in measured singletons. Therefore, in addition to random error in measured singletons. Therefore, in addition to
minimal load measurements to find the systematic error, calibration minimal load measurements to find the systematic error, calibration
measurements should be performed with the same measurement load that measurements should be performed with the same measurement load that
the instruments will see in the field. the instruments will see in the field.
We wish to reiterate that this statistical treatment refers to the We wish to reiterate that this statistical treatment refers to the
calibration of the instrument; it is used to "calibrate the meter calibration of the instrument; it is used to "calibrate the meter
stick" and say how well the meter stick reflects reality. stick" and say how well the meter stick reflects reality.
Network performance measurement with periodic streams Feb 2002
5.6.4 Errors in incT 5.6.4 Errors in incT
The nominal interval between packets, incT, can vary during either The nominal interval between packets, incT, can vary during either
active or passive measurements. In passive measurement, packet active or passive measurements. In passive measurement, packet
headers may include a timestamp applied prior to most of the headers may include a timestamp applied prior to most of the
protocol stack, and the actual sending time may vary due to protocol stack, and the actual sending time may vary due to
processor scheduling. For example, H.323 systems are required to processor scheduling. For example, H.323 systems are required to
have packets ready for the network stack within 5 ms of their ideal have packets ready for the network stack within 5 ms of their ideal
time. There may be additional variation from the network between the time. There may be additional variation from the network between the
Src and the MP(Src). Active measurement systems may encounter Src and the MP(Src). Active measurement systems may encounter
skipping to change at page 12, line 5 skipping to change at line 573
from the measured values. from the measured values.
+ You SHOULD also report the calibration error, e, such that the + You SHOULD also report the calibration error, e, such that the
true value is the reported value plus or minus e, with 95% true value is the reported value plus or minus e, with 95%
confidence (see the last section.) confidence (see the last section.)
+ If possible, the conditions under which a test packet with finite + If possible, the conditions under which a test packet with finite
delay is reported as lost due to resource exhaustion on the delay is reported as lost due to resource exhaustion on the
measurement instrument SHOULD be reported. measurement instrument SHOULD be reported.
5.7.4. Path 5.7.4. Path
Network performance measurement with periodic streams Feb 2002
The path traversed by the packets SHOULD be reported, if possible. The path traversed by the packets SHOULD be reported, if possible.
In general it is impractical to know the precise path a given packet In general it is impractical to know the precise path a given packet
takes through the network. The precise path may be known for takes through the network. The precise path may be known for
certain Type-P packets on short or stable paths. If Type-P includes certain Type-P packets on short or stable paths. If Type-P includes
the record route (or loose-source route) option in the IP header, the record route (or loose-source route) option in the IP header,
and the path is short enough, and all routers on the path support and the path is short enough, and all routers on the path support
record (or loose-source) route, then the path will be precisely record (or loose-source) route, then the path will be precisely
recorded. recorded.
This may be impractical because the route must be short enough, many This may be impractical because the route must be short enough, many
skipping to change at page 13, line 5 skipping to change at line 623
--------------- ---------------
Fig. 1: Different possibilities for performing measurements: a Fig. 1: Different possibilities for performing measurements: a
protocol view. Above, "application" refers to all layers above L4 protocol view. Above, "application" refers to all layers above L4
and is not used in the OSI sense. and is not used in the OSI sense.
In general, the results of measurements may be influenced by In general, the results of measurements may be influenced by
individual application requirements/responses related to the individual application requirements/responses related to the
following issues: following issues:
Network performance measurement with periodic streams Feb 2002
+ Lost packets: Applications may have varying tolerance to lost + Lost packets: Applications may have varying tolerance to lost
packets. Another consideration is the distribution of lost packets packets. Another consideration is the distribution of lost
(i.e. random or bursty). packets (i.e. random or bursty).
+ Long delays: Many applications will consider packets delayed + Long delays: Many applications will consider packets delayed
longer than a certain value to be equivalent to lost packets longer than a certain value to be equivalent to lost packets
(i.e. real time applications). (i.e. real time applications).
+ Duplicate packets: Some applications may be perturbed if + Duplicate packets: Some applications may be perturbed if
duplicate packets are received. duplicate packets are received.
+ Reordering: Some applications may be perturbed if packets arrive + Reordering: Some applications may be perturbed if packets arrive
out of sequence. This may be in addition to the possibility of out of sequence. This may be in addition to the possibility of
exceeding the "long" delay threshold as a result of being out of exceeding the "long" delay threshold as a result of being out of
sequence. sequence.
+ Corrupt packet header: Most applications will probably treat a + Corrupt packet header: Most applications will probably treat a
packet with a corrupt header as equivalent to a lost packet. + packet with a corrupt header as equivalent to a lost packet.
Corrupt packet payload: Some applications (e.g. digital voice + Corrupt packet payload: Some applications (e.g. digital voice
codecs) may accept corrupt packet payload. In some cases, the codecs) may accept corrupt packet payload. In some cases, the
packet payload may contain application specific forward error packet payload may contain application specific forward error
correction (FEC) that can compensate for some level of correction (FEC) that can compensate for some level of
corruption. corruption.
+ Spurious packet: Dst may receive spurious packets (i.e. packets + Spurious packet: Dst may receive spurious packets (i.e. packets
that are not sent by the Src as part of the metric). Many that are not sent by the Src as part of the metric). Many
applications may be perturbed by spurious packets. applications may be perturbed by spurious packets.
Depending, e.g., on the observed protocol level, some issues listed Depending, e.g., on the observed protocol level, some issues listed
above may be indistinguishable from others by the application, it above may be indistinguishable from others by the application, it
skipping to change at page 14, line 4 skipping to change at line 674
International Telecommunications Union (ITU). A framework for IP International Telecommunications Union (ITU). A framework for IP
service level measurements (with references to the framework for IP service level measurements (with references to the framework for IP
performance [3]) that is intended to be suitable for service performance [3]) that is intended to be suitable for service
planning has been approved as I.380 [7]. ITU-T Recommendation I.380 planning has been approved as I.380 [7]. ITU-T Recommendation I.380
covers abstract definitions of performance metrics. This memo covers abstract definitions of performance metrics. This memo
describes a method that is useful both for service planning and end- describes a method that is useful both for service planning and end-
user testing purposes, in both active and passive measurements. user testing purposes, in both active and passive measurements.
Delay measurements can be one-way [3,4], paired one-way, or round- Delay measurements can be one-way [3,4], paired one-way, or round-
trip [8]. Accordingly, the measurements may be performed either with trip [8]. Accordingly, the measurements may be performed either with
Network performance measurement with periodic streams Feb 2002
synchronized or unsynchronized Src/Dst host clocks. Different synchronized or unsynchronized Src/Dst host clocks. Different
possibilities are listed below. possibilities are listed below.
The reference measurement setup for all measurement types is shown The reference measurement setup for all measurement types is shown
in Fig. 2. in Fig. 2.
----------------< IP >-------------------- ----------------< IP >--------------------
| | | | | | | |
------- ------- -------- -------- ------- ------- -------- --------
| Src | | MP | | MP | | Dst | | Src | | MP | | MP | | Dst |
skipping to change at page 15, line 4 skipping to change at line 726
6.1.1 One way measurement 6.1.1 One way measurement
In the interests of specifying metrics that are as generally usable In the interests of specifying metrics that are as generally usable
as possible, application-level measurements based on one-way delays as possible, application-level measurements based on one-way delays
are used in the example metrics. The implication of application- are used in the example metrics. The implication of application-
level measurement for bi-directional applications such as level measurement for bi-directional applications such as
interactive multimedia conferencing is discussed below. interactive multimedia conferencing is discussed below.
Performing a single one-way measurement only yields information on Performing a single one-way measurement only yields information on
network behavior in one direction. Moreover, the stream at the network behavior in one direction. Moreover, the stream at the
Network performance measurement with periodic streams Feb 2002
network transport level does not emulate accurately a full-duplex network transport level does not emulate accurately a full-duplex
multimedia connection. multimedia connection.
6.1.2 Paired one way measurement 6.1.2 Paired one way measurement
Paired one way delay refers to two multimedia streams: Src to Dst Paired one way delay refers to two multimedia streams: Src to Dst
and Dst to Src for the same Src and Dst. By way of example, for some and Dst to Src for the same Src and Dst. By way of example, for some
applications, the delay performance of each one way path is more applications, the delay performance of each one way path is more
important than the round trip delay. This is the case for delay- important than the round trip delay. This is the case for delay-
limited signals such as VoIP. Possible reasons for the difference limited signals such as VoIP. Possible reasons for the difference
skipping to change at page 16, line 5 skipping to change at line 775
returning stream may experience worse QoS than the out-going one, returning stream may experience worse QoS than the out-going one,
and the performance estimates thus obtained are pessimistic ones. and the performance estimates thus obtained are pessimistic ones.
The possibility of asymmetric routing and queuing must be taken into The possibility of asymmetric routing and queuing must be taken into
account during analysis of the results. account during analysis of the results.
Note that with suitable arrangements, round-trip measurements may be Note that with suitable arrangements, round-trip measurements may be
performed using paired one way measurements. performed using paired one way measurements.
6.2 Statistics calculable from one sample 6.2 Statistics calculable from one sample
Network performance measurement with periodic streams Feb 2002
Some statistics may be particularly relevant to applications Some statistics may be particularly relevant to applications
simulated by periodic streams, such as the range of delay values simulated by periodic streams, such as the range of delay values
recorded during the sample. recorded during the sample.
For example, a sample metric generates 100 packets at MP(Src) with For example, a sample metric generates 100 packets at MP(Src) with
the following measurements at MP(Dst): the following measurements at MP(Dst):
+ 80 packets received with delay [i] <= 20 ms + 80 packets received with delay [i] <= 20 ms
+ 8 packets received with delay [i] > 20 ms + 8 packets received with delay [i] > 20 ms
+ 5 packets received with corrupt packet headers + 5 packets received with corrupt packet headers
+ 4 packets from MP(Src) with no matching packet recorded + 4 packets from MP(Src) with no matching packet recorded at
at MP(Dst) (effectively lost) MP(Dst) (effectively lost)
+ 3 packets received with corrupt packet payload and delay [i] <= + 3 packets received with corrupt packet payload and
20 ms delay [i] <= 20 ms
+ 2 packets that duplicate one of the 80 packets received + 2 packets that duplicate one of the 80 packets received
correctly as indicated in the first item correctly as indicated in the first item
For this example, packets are considered acceptable if they are For this example, packets are considered acceptable if they are
received with less than or equal to 20ms delays and without corrupt received with less than or equal to 20ms delays and without corrupt
packet headers or packet payload. In this case, the percentage of packet headers or packet payload. In this case, the percentage of
acceptable packets is 80/100 = 80%. acceptable packets is 80/100 = 80%.
For a different application which will accept packets with corrupt For a different application which will accept packets with corrupt
packet payload and no delay bound (so long as the packet is packet payload and no delay bound (so long as the packet is
skipping to change at page 16, line 53 skipping to change at line 821
samples over different intervening link-host combinations) should be samples over different intervening link-host combinations) should be
taken into account. For items like the interval between samples, taken into account. For items like the interval between samples,
the usage pattern for the application of interest should be the usage pattern for the application of interest should be
considered. considered.
When computing statistics for multiple samples, more general When computing statistics for multiple samples, more general
statistics (e.g. median, percentile, etc.) may have relevance with a statistics (e.g. median, percentile, etc.) may have relevance with a
larger number of packets. larger number of packets.
6.4 Background conditions 6.4 Background conditions
In many cases, the results may be influenced by conditions at Src, In many cases, the results may be influenced by conditions at Src,
Dst, and/or any intervening networks. Factors that may affect the Dst, and/or any intervening networks. Factors that may affect the
results include: traffic levels and/or bursts during the sample, results include: traffic levels and/or bursts during the sample,
link and/or host failures, etc. Information about the background link and/or host failures, etc. Information about the background
conditions may only be available by external means (e.g. phone conditions may only be available by external means (e.g. phone
Network performance measurement with periodic streams Feb 2002
calls, television) and may only become available days after samples calls, television) and may only become available days after samples
are taken. are taken.
6.5 Considerations related to delay 6.5 Considerations related to delay
For interactive multimedia sessions, end-to-end delay is an For interactive multimedia sessions, end-to-end delay is an
important factor. Too large a delay reduces the quality of the important factor. Too large a delay reduces the quality of the
multimedia session as perceived by the participants. One approach multimedia session as perceived by the participants. One approach
for managing end-to-end delays on an Internet path involving for managing end-to-end delays on an Internet path involving
heterogeneous link layer technologies is to use per-domain delay heterogeneous link layer technologies is to use per-domain delay
skipping to change at page 18, line 4 skipping to change at line 878
stored for length analysis, suitable precautions MUST be taken to stored for length analysis, suitable precautions MUST be taken to
keep this information safe and confidential. keep this information safe and confidential.
7.3 Interference with the metric 7.3 Interference with the metric
It may be possible to identify that a certain packet or stream of It may be possible to identify that a certain packet or stream of
packets is part of a sample. With that knowledge at Dst and/or the packets is part of a sample. With that knowledge at Dst and/or the
intervening networks, it is possible to change the processing of the intervening networks, it is possible to change the processing of the
packets (e.g. increasing or decreasing delay) that may distort the packets (e.g. increasing or decreasing delay) that may distort the
measured performance. It may also be possible to generate measured performance. It may also be possible to generate
Network performance measurement with periodic streams Feb 2002
additional packets that appear to be part of the sample metric. additional packets that appear to be part of the sample metric.
These additional packets are likely to perturb the results of the These additional packets are likely to perturb the results of the
sample measurement. sample measurement.
To discourage the kind of interference mentioned above, packet To discourage the kind of interference mentioned above, packet
interference checks, such as cryptographic hash, may be used. interference checks, such as cryptographic hash, MAY be used.
8. IANA Considerations 8. IANA Considerations
Since this method and metric do not define a protocol or well-known Since this method and metric do not define a protocol or well-known
values, there are no IANA considerations in this memo. values, there are no IANA considerations in this memo.
9. References 9. Normative References
1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996. 9, RFC 2026, October 1996.
2 Bradner, S., "Key words for use in RFCs to Indicate Requirement 2 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997. Levels", RFC 2119, March 1997.
3 Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., "Framework 3 Paxson, V., Almes, G., Mahdavi, J., and Mathis, M., "Framework
for IP Performance Metrics", RFC 2330, May 1998. for IP Performance Metrics", RFC 2330, May 1998.
4 Almes, G., Kalidindi, S., and Zekauskas, M., "A one-way delay 4 Almes, G., Kalidindi, S., and Zekauskas, M., "A one-way delay
metric for IPPM", RFC 2679, September 1999. metric for IPPM", RFC 2679, September 1999.
10. Informative References
5 Demichelis, C., and Chimento, P., "IP Packet Delay Variation 5 Demichelis, C., and Chimento, P., "IP Packet Delay Variation
Metric for IPPM", work in progress. Metric for IPPM", work in progress.
6 "End-to-end Quality of Service in TIPHON systems; Part 5: Quality 6 "End-to-end Quality of Service in TIPHON systems; Part 5: Quality
of Service (QoS) measurement methodologies", ETSI standard TS 101 of Service (QoS) measurement methodologies", ETSI standard TS 101
329-5 V1.1.2 (2002-01). 329-5 V1.1.2 (2002-01).
7 International Telecommunications Union, "Internet protocol data 7 International Telecommunications Union, "Internet protocol data
communication service _ IP packet transfer and availability communication service _ IP packet transfer and availability
performance parameters", Telecommunications Sector Recommendation performance parameters", Telecommunications Sector Recommendation
I.380 (to be re-designated Y.1540), February 1999. I.380 (to be re-designated Y.1540), February 1999.
8 Almes, G., Kalidindi, S., and Zekauskas, M., "A round-trip delay 8 Almes, G., Kalidindi, S., and Zekauskas, M., "A round-trip delay
metric for IPPM", IETF RFC 2681. metric for IPPM", IETF RFC 2681.
10. Acknowledgments 11. Acknowledgments
The authors wish to thank the chairs of the IPPM WG (Matt Zekauskas The authors wish to thank the chairs of the IPPM WG (Matt Zekauskas
and Merike Kaeo) for comments that have made the present draft and Merike Kaeo) for comments that have made the present draft
clearer and more focused. Howard Stanislevic and Will Leland have clearer and more focused. Howard Stanislevic and Will Leland have
also presented useful comments and questions. We also acknowledge also presented useful comments and questions. We also acknowledge
Henk Uijterwaal's continued challenge to develop the motivation for Henk Uijterwaal's continued challenge to develop the motivation for
this method. The authors have built on the substantial foundation this method. The authors have built on the substantial foundation
laid by the authors of the framework for IP performance [3]. laid by the authors of the framework for IP performance [3].
Network performance measurement with periodic streams Feb 2002 12. Author's Addresses
11. Author's Addresses
Vilho Raisanen Vilho Raisanen
Nokia Networks Nokia Networks
P.O. Box 300 P.O. Box 300
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
Phone +358 7180 8000 Fax. +358 9 4376 6852 Phone +358 7180 8000 Fax. +358 9 4376 6852
<Vilho.Raisanen@nokia.com> <Vilho.Raisanen@nokia.com>
Glenn Grotefeld Glenn Grotefeld
 End of changes. 

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