draft-ietf-ippm-npmps-02.txt   draft-ietf-ippm-npmps-03.txt 
Network Working Group V. Raisanen Network Working Group V. Raisanen
INTERNET-DRAFT Nokia INTERNET-DRAFT Nokia
Expiration Date: January 2001 G. Grotefeld Expiration Date: May 2001 G. Grotefeld
Motorola Motorola
July 2000 November 2000
Network performance measurement for periodic streams Network performance measurement for periodic streams
<draft-ietf-ippm-npmps-02.txt> <draft-ietf-ippm-npmps-03.txt>
1. Status of this Memo 1. 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. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at line 37 skipping to change at line 37
The list of Internet-Draft shadow directories can be accessed at The list of Internet-Draft shadow directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This memo provides information for the Internet community. This This memo provides information for the Internet community. This
memo does not specify an Internet standard of any memo does not specify an Internet standard of any
kind. Distribution of this memo is unlimited. kind. Distribution of this memo is unlimited.
2. Abstract 2. Abstract
This document describes some of the issues associated with This document describes a sample metric suitable for application-
application-level measurements of network performance for periodic level IP network transport measurement for periodic streams, such as
streams. An example application would be the testing of Dst-Src routes VoIP or streaming multimedia over IP. In this document, the reader
for use as bearer for multimedia streams. In this document, is assumed to be familiar with the terminology of the Framework for
the reader is assumed to be familiar with the terminology of the IP Performance Metrics RFC 2330 [1]. This document is parallel to
Framework for IP Performance Metrics RFC 2330 [1]. This document is A One-way Delay Metric for IPPM RFC 2679 [2]. Although this document
parallel to A One-way Delay Metric for IPPM RFC 2679 [2]. A sample is based on the delay metrics, other characteristics can be measured
metric is described that is suitable for application-level measurement with this approach, too. For example, packet loss rate, reordering /
for streaming multimedia over IP. Using such a measurement, out-of sequence, and successive delay variation are all additional
transmission service of a network is probed with a traffic stream metrics which can be built from this baseline set of measurements.
similar to that of the application of interest, which is likely to be
very dissimilar to the Poisson inter-arrival interval described in [2].
Raisanen, Grotefeld expires January 2001 [Page 1] Raisanen, Grotefeld expires May 2001 [Page 1]
3. Introduction 3. Introduction
This document discusses concepts relevant to application-level This document discusses concepts relevant to application-level
performance measurements of an IP network. The original driver for performance measurements of an IP network. The original driver for
this work is Quality of Service of interactive periodic streams such this work is Quality of Service of interactive periodic streams such
as multimedia conference over IP, but the idea of application-level as multimedia conference over IP, but the idea of application-level
measurement may have a wider scope. In the following, interactive measurement may have a wider scope. In the following, interactive
multimedia traffic is used as an example to illustrate the concept. multimedia traffic is used as an example to illustrate the concept.
skipping to change at line 96 skipping to change at line 94
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 [4]. document are to be interpreted as described in RFC 2119 [4].
Although RFC 2119 was written with protocols in mind, the key words Although RFC 2119 was written with protocols in mind, the key words
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 implementations ensure the results of measurements from two different implementations
are comparable, and to note instances when an implementation could are comparable, and to note instances when an implementation could
perturb the network. perturb the network.
Raisanen, Grotefeld expires January 2001 [Page 2] Raisanen, Grotefeld expires May 2001 [Page 2]
3.2 Considerations related to delay 3.2 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 for multimedia session as perceived by the participants. One approach for
managing end-to-end delays on an Internet path involving 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
quotas (e.g. 50 ms for a particular IP domain). The 50 ms would quotas (e.g. 50 ms for a particular IP domain). The 50 ms would
then be included into a calculation of an end-to-end delay bound. A then be included into a calculation of an end-to-end delay bound. A
skipping to change at line 134 skipping to change at line 132
could study the quality of a cheap, low-guarantee service could study the quality of a cheap, low-guarantee service
implemented using possible slack bandwidth in other classes. Such implemented using possible slack bandwidth in other classes. Such
measurements could be made either in studying the feasibility of a measurements could be made either in studying the feasibility of a
new service, or on a regular basis. new service, or on a regular basis.
The present draft seeks to formalize the measurements in such a way The present draft seeks to formalize the measurements in such a way
that interoperable results are achieved. that interoperable results are achieved.
3.3 Protocol level issues 3.3 Protocol level issues
The version of the Internet Protocol used in the measurement affects
(at least) packet sizes, and should be reported.
Fig.1 illustrates measurements on multiple protocol levels that Fig.1 illustrates measurements on multiple protocol levels that
are relevant to this draft. The major focus of the present draft are relevant to this draft. The major focus of the present draft
is on transport quality evaluation from application point of is on transport quality evaluation from application point of
view. However, to properly account for quality effects of, e.g., view. However, to properly account for quality effects of, e.g.,
operating system and codec on packet voice, it is beneficial to be operating system and codec on packet voice, it is beneficial to be
able to measure quality at IP level [5]. Link layer monitoring able to measure quality at IP level [5]. Link layer monitoring
provides a way of accounting for link layer characteristics such provides a way of accounting for link layer characteristics such
as bit error rates. as bit error rates.
Raisanen, Grotefeld expires January 2001 [Page 3] Raisanen, Grotefeld expires May 2001 [Page 3]
--------------- ---------------
| application | | application |
--------------- ---------------
| transport | <-- | transport | <--
--------------- ---------------
| network | <-- | network | <--
--------------- ---------------
| link | <-- | link | <--
--------------- ---------------
| physical | | physical |
skipping to change at line 172 skipping to change at line 173
following issues: following issues:
+ 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. Another consideration is the distribution of lost
packets (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.
+ Out of sequence: Some applications may be perturbed if + Out-of-sequence: Some applications may be perturbed if packets
packets are received out of sequence. This may be in addition are received out of sequence. This may be in addition to the
to the possibility of exceeding the "long" delay threshold as a possibility of exceeding the "long" delay threshold as a result
result of being out of sequence. of being out of sequence. An out-of-sequence packet outcome
occurs when a single IP packet received at a DST measurement
point has a sequence number higher than that which is
expected, and therefore, the packet is OOS due to re-ordering.
+ 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 part of the metric). Many applications may be that are not sent by the Src as part of the metric). Many
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
may be important to preserve the distinction for the operators of may be important to preserve the distinction for the operators of
Src, Dst, and/or the intermediate network(s). Src, Dst, and/or the intermediate network(s).
Raisanen, Grotefeld expires January 2001 [Page 4] Raisanen, Grotefeld expires May 2001 [Page 4]
Because of the possible errors listed above, in most cases it is Because of the possible errors listed above, in most cases it is
recommended to use a packet identifier for each packet generated at recommended to use a packet identifier for each packet generated at
Src. Identifiers for the metric sample may be those used by the Src. Identifiers for the metric sample may be those used by the
underlying transport layer (e.g. RTP sequence number) or the same underlying transport layer (e.g. RTP sequence number) or the same
identifiers used by an application if the application to be modeled identifiers used by an application if the application to be modeled
by the metric uses an identifier. The possibility of identifier by the metric uses an identifier. The possibility of identifier
roll-over (reuse if intentional) during a metric collected over roll-over (reuse if intentional) during a metric collected over
a "long" (application dependent) time should be observed. a "long" (application dependent) time should be observed.
If the application does not use an identifier, it may still be If the application does not use an identifier, it may still be
skipping to change at line 236 skipping to change at line 240
3.5 Measurement types 3.5 Measurement types
Delay measurements can be one-way [2,3], paired one-way, or Delay measurements can be one-way [2,3], paired one-way, or
round-trip [6]. Accordingly, the measurements may be performed round-trip [6]. Accordingly, the measurements may be performed
either with synchronized or unsynchronized Src/Dst host clocks. either with synchronized or unsynchronized Src/Dst host clocks.
Different possibilities are listed below. Different possibilities are listed below.
The reference measurement setup for all measurement types is The reference measurement setup for all measurement types is
shown in Fig. 2. shown in Fig. 2.
Raisanen, Grotefeld expires January 2001 [Page 5] Raisanen, Grotefeld expires May 2001 [Page 5]
----------------< IP >-------------------- ----------------< IP >--------------------
| | | | | | | |
------- ------- -------- -------- ------- ------- -------- --------
| Src | | MP | | MP | | Dst | | Src | | MP | | MP | | Dst |
------- |(Src)| |(Dst) | -------- ------- |(Src)| |(Dst) | --------
------- -------- ------- --------
Fig. 2: Example setup for the metric usage. Fig. 2: Example setup for the metric usage.
An example of the use of the metric is a setup with a source host An example of the use of the metric is a setup with a source host
(Src), a destination host (Dst), and corresponding measurement (Src), a destination host (Dst), and corresponding measurement
points (MP(Src) and MP(Dst)) as shown in Figure 2. Separate equipment points (MP(Src) and MP(Dst)) as shown in Figure 2. Separate equipment
for measurement points may be used if having Src and/or Dst conduct for measurement points may be used if having Src and/or Dst conduct
the measurement may significantly affect the delay performance to be the measurement may significantly affect the delay performance to be
measured. MP(Src)should be placed/measured close to the egress point measured. MP(Src)should be placed/measured close to the egress point
of packets from Src. MP(Dst) should be placed/measure close to of packets from Src. MP(Dst) should be placed/measure close to
the ingress point of packets for Dst. "Close" is defined as a the ingress point of packets for Dst. "Close" is defined as a
distance sufficiently small so that application-level performance distance sufficiently small so that application-level performance
characteristics measured (such as delay) can be expected to follow characteristics measured (such as delay) can be expected to follow
the corresponding performance characteristic between Src and Dst to the corresponding performance characteristic between Src and Dst to
an adequate accuracy. an adequate accuracy. Basic principle here is that measurement
results between MP(Src) and MP(Dst) should be the same as for a
measurement between Src and Dst, within the general error margin
target of the measurement (e.g., < 1 ms; number of lost packets is
the same). If this is not possible, the difference between MP-MP
measurement and Src-Dst measurement should preferably be systematic.
The test setup just described fulfills two important criteria: The test setup just described fulfills two important criteria:
1) Test is made with realistic stream metrics, emulating - for example - 1) Test is made with realistic stream metrics, emulating - for example -
a full-duplex Voice over IP (VoIP) call. a full-duplex Voice over IP (VoIP) call.
2) Either one-way or round-trip characteristics may be obtained. 2) Either one-way or round-trip characteristics may be obtained.
It is also possible to have intermediate measurement points between It is also possible to have intermediate measurement points between
MP(Src) and MP(Dst), but that is beyond the scope of this document. MP(Src) and MP(Dst), but that is beyond the scope of this document.
3.5.1 One way measurement 3.5.1 One way measurement
skipping to change at line 280 skipping to change at line 289
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-level are used in the example metrics. The implication of application-level
measurement for bi-directional applications such as interactive measurement for bi-directional applications such as interactive
multimedia conferencing is discussed below. 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 transport level does not emulate accurately a full-duplex network transport level does not emulate accurately a full-duplex
multimedia connection. multimedia connection.
Raisanen, Grotefeld expires January 2001 [Page 6] Raisanen, Grotefeld expires May 2001 [Page 6]
3.5.2 Paired one way measurement 3.5.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 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 some applications, the delay performance of each one way path is
more important than the round trip delay. This is the case for more important than the round trip delay. This is the case for
delay-limited signals such as VoIP. Possible reasons for the delay-limited signals such as VoIP. Possible reasons for the
difference between one-way delays is different routing of streams difference between one-way delays is different routing of streams
from Src to Dst vs. Dst to Src. from Src to Dst vs. Dst to Src.
skipping to change at line 327 skipping to change at line 336
original sender may be more bursty than the one on the first "leg" of original sender may be more bursty than the one on the first "leg" of
the round-trip journey. The last issue, however, means in practice the round-trip journey. The last issue, however, means in practice
that returning stream experiences worse QoS than the other one, and that returning stream experiences worse QoS than the other one, and
the performance estimates thus obtained are pessimistic ones. The the performance estimates thus obtained are pessimistic ones. The
possibility of asymmetric routing and queuing must be taken into possibility of asymmetric routing and queuing must be taken into
account during analysis of the results. account during analysis of the results.
Please note that with suitable arrangements, round-trip measurements Please note that with suitable arrangements, round-trip measurements
may be performed using paired one way measurements. may be performed using paired one way measurements.
Raisanen, Grotefeld expires January 2001 [Page 7] Raisanen, Grotefeld expires May 2001 [Page 7]
4 Sample metric for multimedia stream simulation 4 Sample metric for multimedia stream simulation
The sample metric presented here is similar to the sample metric The sample metric presented here is similar to the sample metric
Type-P-One-way-Delay-Poisson-Stream presented in [2]. "Singletons", as Type-P-One-way-Delay-Poisson-Stream presented in [2]. "Singletons", as
defined in [1] and [2] are not directly used in this document because defined in [1] and [2] are not directly used in this document because
certain key results (such as duplicate or out of sequence packets) certain key results (such as duplicate or out of sequence packets)
cannot be identified in the context of a singleton, but only as part cannot be identified in the context of a singleton, but only as part
of a sample. of a sample.
skipping to change at line 351 skipping to change at line 360
4.2 Metric parameters 4.2 Metric parameters
4.2.1 Global metric parameters 4.2.1 Global metric parameters
These parameters are applicable to the metrics collected in the These parameters are applicable to the metrics collected in the
following sections (4.2.2, 4.2.3, and 4.2.4). following sections (4.2.2, 4.2.3, and 4.2.4).
+ Src, the IP address of a host + Src, the IP address of a host
+ Dst, the IP address of a host + Dst, the IP address of a host
+ IPV, the IP version (IPv4/IPv6) used in the measurement
+ T0, a time, for starting to generate packets and taking + T0, a time, for starting to generate packets and taking
measurements for a sample measurements for a sample
+ 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 for a sample
+ periodic packet interval incT, a time duration + periodic packet interval incT, a time duration
+ packet size p(j), the number of bytes in each packet of Type-P of + packet size p(j), the number of bytes in each packet of Type-P of
size j size j
+ dTloss, a time interval, used for determining if a packet should + dTloss, a time interval, used for determining if a packet should
be considered lost be considered lost
+ Tcons, a time interval [optional] + Tcons, a time interval [optional]
skipping to change at line 373 skipping to change at line 383
other applications may use packets of different sizes (j > 1). other applications may use packets of different sizes (j > 1).
Especially in cases of congestion, it may be useful to have Especially in cases of congestion, it may be useful to have
packets smaller than the maximum or predominant size of packets packets smaller than the maximum or predominant size of packets
in the periodic stream. in the periodic stream.
4.2.2 Metrics collected at MP(Src) 4.2.2 Metrics collected at MP(Src)
+ 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)
+ PktID [i], for each packet [i], an identification number for the + PktID [i], for each packet [i], an identification number for the
the packet sent from Src to Dst the packet sent from Src to Dst.
Raisanen, Grotefeld expires January 2001 [Page 8] Raisanen, Grotefeld expires May 2001 [Page 8]
+ PktSiTy [i], for each packet [i], the packet size and/or type. + PktSiTy [i], for each packet [i], the packet size and/or type.
Some applications may use packets of different size, either Some applications may use packets of different size, either
because of application requirements or in response to IP because of application requirements or in response to IP
performance experienced. performance experienced.
4.2.3 Metrics collected at MP (Dst) 4.2.3 Metrics collected at MP (Dst)
+ dTstop, a time interval, used to add to time Tf to determine when to + dTstop, a time interval, used to add to time Tf to determine when to
stop collecting metrics for a sample stop collecting metrics for a sample
+ Tstamp(Dst)[i], for each packet [i], the time of the packet as + Tstamp(Dst)[i], for each packet [i], the time of the packet as
measured at MP(Dst) measured at MP(Dst)
+ PktID [i], for each packet [i], an identification number for the + PktID [i], for each packet [i], an identification number for the
the packet received at Dst from Src. This identification number the packet received at Dst from Src.
may be corrupted.
+ PktSiTy [i], for each packet [i], the packet size and/or type. + PktSiTy [i], for each packet [i], the packet size and/or type.
Some applications may use packets of different size, either Some applications may use packets of different size, either
because of application requirements or in response to IP because of application requirements or in response to IP
performance experienced. performance experienced.
+ PktStatus [i], for each packet [i], the status of the packet + PktStatus [i], for each packet [i], the status of the packet
received. Possible status includes: OK, packet header corrupt, received. Possible status includes: OK, packet header corrupt,
packet payload corrupt, spurious, duplicate packet payload corrupt, spurious, duplicate, out-of-sequence.
4.2.4 Metrics resulting when metrics collected at MP(Src) and MP(Dst) 4.2.4 Metrics resulting when metrics collected at MP(Src) and MP(Dst)
are merged are merged
These parameters are only available as a complete set when the These parameters are only available as a complete set when the
parameters from the preceding sections (4.2.1, 4.2.2, and 4.2.3 are parameters from the preceding sections (4.2.1, 4.2.2, and 4.2.3 are
combined. combined.
+ 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). This entry may be blank or noted as N/A measured at MP(Src). This entry may be blank or noted as N/A
skipping to change at line 418 skipping to change at line 427
+ Tstamp(Dst)[i], for each packet [i], the time of the packet as + Tstamp(Dst)[i], for each packet [i], the time of the packet as
measured at MP(Dst). This entry may be blank or noted as N/A measured at MP(Dst). This entry may be blank or noted as N/A
for packets not received at MP(Dst), received with corrupt for packets not received at MP(Dst), received with corrupt
packet headers, or for duplicate packets received at MP(Dst). packet headers, or for duplicate packets received at MP(Dst).
+ PktID [i], for each packet [i], an identification number for the + PktID [i], for each packet [i], an identification number for the
the packet received. This identification number may be corrupted the packet received. This identification number may be corrupted
for certain packets received at MP (Dst). for certain packets received at MP (Dst).
+ PktSiTy [i], for each packet [i], the packet size and/or type. + PktSiTy [i], for each packet [i], the packet size and/or type.
+ PktStatus [i], for each packet [i], the status of the packet + PktStatus [i], for each packet [i], the status of the packet
received. Possible status includes: OK, packet header corrupt, received. Possible status includes: OK, packet header corrupt,
packet payload corrupt, spurious, duplicate, out of sequence. packet payload corrupt, spurious, duplicate, out-of-sequence.
Raisanen, Grotefeld expires January 2001 [Page 9] Raisanen, Grotefeld expires May 2001 [Page 9]
+ Delay [i], for each packet [i], the time interval Tstamp(Dst)[i] - + Delay [i], for each packet [i], the time interval Tstamp(Dst)[i] -
Tstamp(Src)[i]. For the following conditions, it will not be Tstamp(Src)[i]. For the following conditions, it will not be
possible to be able to compute delay: possible to be able to compute delay:
Spurious: There will be no Tstamp(Src)[i] time Spurious: There will be no Tstamp(Src)[i] time
Not received: There will be no Tstamp (Dst) [i] Not received: There will be no Tstamp (Dst) [i]
Corrupt packet header: There will be no Tstamp (Dst) [i] Corrupt packet header: There will be no Tstamp (Dst) [i]
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.
+ SDV[i] [optional] , for each packet [i] except the first one: + SDV[i] [optional] , for each packet [i] except the first one:
momentary delay variation between successive packets, i.e., the momentary delay variation between successive packets, i.e., the
skipping to change at line 462 skipping to change at line 471
packet size/type, and received status of each packet received from packet size/type, and received status of each packet received from
Src at Dst that is part of the sample. Optionally, at a time Tf + Src at Dst that is part of the sample. Optionally, at a time Tf +
Tcons, the data from MP(Src) and MP(Dst) are consolidated to derive Tcons, the data from MP(Src) and MP(Dst) are consolidated to derive
the results of the sample metric. the results of the sample metric.
To prevent stopping data collection too soon, dTcons should be greater To prevent stopping data collection too soon, dTcons should be greater
than or equal to dTstop. Conversely, to keep data collection than or equal to dTstop. Conversely, to keep data collection
reasonably efficient, dTstop should be some reasonable time interval reasonably efficient, dTstop should be some reasonable time interval
(seconds/minutes/hours), even if dTloss is infinite or extremely long. (seconds/minutes/hours), even if dTloss is infinite or extremely long.
Raisanen, Grotefeld expires January 2001 [Page 10] Raisanen, Grotefeld expires May 2001 [Page 10]
4.4 Discussion 4.4 Discussion
The sample metric thus defined is intended to probe the delays and The sample metric thus defined is intended to probe the delays and
the delay variation as experienced by multimedia streams of the delay variation as experienced by multimedia streams of
an application. Subsequently, the delay is assumed to be measured at an application. Subsequently, the delay is assumed to be measured at
transport layer level. Since a range of packet sizes and nominal transport layer level. Since a range of packet sizes and nominal
interval between packets is used, the method probes only a specific interval between packets is used, the method probes only a specific
time scale of network QoS variations. time scale of network QoS variations.
skipping to change at line 509 skipping to change at line 518
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 to
synchronize very closely. GPS systems afford one way to achieve synchronize very closely. GPS systems afford one way to achieve
synchronization to within several 10s of usec. Ordinary application synchronization to within several 10s of usec. Ordinary application
of NTP may allow synchronization to within several msec, but this of NTP may allow synchronization to within several msec, but this
depends on the stability and symmetry of delay properties among those depends on the stability and symmetry of delay properties among those
NTP agents used, and this delay is what we are trying to measure. A NTP agents used, and this delay is what we are trying to measure. A
combination of some GPS-based NTP servers and a conservatively combination of some GPS-based NTP servers and a conservatively
designed and deployed set of other NTP servers should yield good designed and deployed set of other NTP servers should yield good
results, but this is yet to be tested. results, but this is yet to be tested.
Raisanen, Grotefeld expires January 2001 [Page 11] + Reordering of packets is best discussed in terms of the entire
set of measurement packets received, i.e. should be addressed in
Sec. 4.9.1.
Raisanen, Grotefeld expires May 2001 [Page 11]
+ 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 (and
the packet is yet to arrive at Dst). The global metric parameter the packet is yet to arrive at Dst). The global metric parameter
dTloss defines a time interval such that delays larger than dTloss dTloss defines a time interval such that delays larger than dTloss
are interpreted as losses. are interpreted as losses.
{Comment: Note that, for many applications of these metrics, the {Comment: Note that, for many applications of these metrics, the
harm in treating a large delay as infinite might be zero or very harm in treating a large delay as infinite might be zero or very
small. A TCP data packet, for example, that arrives only after small. A TCP data packet, for example, that arrives only after
several multiples of the RTT may as well have been lost.} several multiples of the RTT may as well have been lost.}
skipping to change at line 558 skipping to change at line 571
+ 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 the MP(Dst) clock will contribute to error in the delay
measurement. We say that the MP(Src) clock and the MP(Dst) measurement. We say that the MP(Src) clock and the MP(Dst)
clock have a synchronization error of Tsynch if the MP(Src) clock clock have a synchronization error of Tsynch if the MP(Src) clock
is Tsynch ahead of the MP(Dst) clock. Thus, if we know the is Tsynch ahead of the MP(Dst) clock. Thus, if we know the
value of Tsynch exactly, we could correct for clock value of Tsynch exactly, we could correct for clock
synchronization by adding Tsynch to the uncorrected value of synchronization by adding Tsynch to the uncorrected value of
Tstamp(Dst)[i] - Tstamp(Src) [i]. Tstamp(Dst)[i] - Tstamp(Src) [i].
Raisanen, Grotefeld expires January 2001 [Page 12] Raisanen, Grotefeld expires May 2001 [Page 12]
+ The accuracy of a clock is important only in identifying the time + The accuracy of a clock is important only in identifying the time
at which a given delay was measured. Accuracy, per se, has no at which a given delay was measured. Accuracy, per se, has no
importance to the accuracy of the measurement of delay. When importance to the accuracy of the measurement of delay. When
computing delays, we are interested only in the differences computing delays, we are interested only in the differences
between clock values, not the values themselves. between clock values, not the values themselves.
+ 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
skipping to change at line 608 skipping to change at line 621
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
process the packet after having received the test packet, and we refer process the packet after having received the test packet, and we refer
to these two points as "host times". 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 time accurately known, this knowledge can be used to correct for wire time
measurements and the corrected value more accurately estimates the measurements and the corrected value more accurately estimates the
desired (host time) metric. desired (host time) metric.
Raisanen, Grotefeld expires January 2001 [Page 13] Raisanen, Grotefeld expires May 2001 [Page 13]
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
analysis of a given measurement method. We denote by Hsource an analysis of a given measurement method. We denote by Hsource an
upper bound on the uncertainty in the difference between wire time upper bound on the uncertainty in the difference between wire time
of MP(Src) and host time on the Src host, and similarly define Hdest of MP(Src) and host time on the Src host, and similarly define Hdest
for the difference between the host time on the Dst host and the wire for the difference between the host time on the Dst host and the wire
time of MP(Dst). We then note that these problems introduce a total time of MP(Dst). We then note that these problems introduce a total
uncertainty of Hsource+Hdest. This estimate of total wire-vs-host uncertainty of Hsource+Hdest. This estimate of total wire-vs-host
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.
skipping to change at line 655 skipping to change at line 668
remove outliers, which will be found in measuring any physical remove outliers, which will be found in measuring any physical
property; (2) a particular confidence level should be specified so property; (2) a particular confidence level should be specified so
that the results of independent implementations can be compared.} that the results of independent implementations can be 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
Esynch(t) + ResMP(Src) + ResMP(Dst) + Hsource + Hdest. Esynch(t) + ResMP(Src) + ResMP(Dst) + Hsource + Hdest.
Raisanen, Grotefeld expires January 2001 [Page 14] Raisanen, Grotefeld expires May 2001 [Page 14]
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) +
ResMP(Src) + ResMP(Dst) is small, and is also bounded for the ResMP(Src) + ResMP(Dst) is small, and is also bounded for the
duration of the measurement because of the global time source. duration of the measurement because of the global time source.
skipping to change at line 703 skipping to change at line 716
Note that random error is a function of measurement load. For Note that random error is a function of measurement load. For
example, if many paths will be measured by one instrument, this might example, if many paths will be measured by one instrument, this might
increase interrupts, process scheduling, and disk I/O (for example, increase interrupts, process scheduling, and disk I/O (for example,
recording the measurements), all of which may increase the random recording the measurements), all of which may increase the random
error in measured singletons. Therefore, in addition to minimal load error in measured singletons. Therefore, in addition to minimal load
measurements to find the systematic error, calibration measurements measurements to find the systematic error, calibration measurements
should be performed with the same measurement load that the should be performed with the same measurement load that the
instruments will see in the field. instruments will see in the field.
Raisanen, Grotefeld expires January 2001 [Page 15] Raisanen, Grotefeld expires May 2001 [Page 15]
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.
4.7 Reporting the metric 4.7 Reporting the metric
The calibration and context in which the metric is measured MUST be The calibration and context in which the metric is measured MUST be
carefully considered, and SHOULD always be reported along with metric carefully considered, and SHOULD always be reported along with metric
results. We now present five items to consider: the Type-P of test results. We now present five items to consider: the Type-P of test
packets, the threshold of delay equivalent to loss, error packets, the threshold of delay equivalent to loss, error
skipping to change at line 747 skipping to change at line 760
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.
Raisanen, Grotefeld expires January 2001 [Page 16] Raisanen, Grotefeld expires May 2001 [Page 16]
4.7.4. Path 4.7.4. Path
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
skipping to change at line 796 skipping to change at line 809
test 1,000 two-minute VoIP calls rather than a single 2,000 minute test 1,000 two-minute VoIP calls rather than a single 2,000 minute
VoIP call. When considering collection of a sample of samples, issues VoIP call. When considering collection of a sample of samples, issues
like the interval between samples (e.g. Poisson vs. periodic, time of like the interval between samples (e.g. Poisson vs. periodic, time of
day/day of week), composition of samples (e.g. equal (Tf-T0 duration, day/day of week), composition of samples (e.g. equal (Tf-T0 duration,
different packet sizes), and network considerations (e.g. run different different packet sizes), and network considerations (e.g. run different
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 pattern of use of the application being measured should be the pattern of use of the application being measured should be
considered. considered.
Raisanen, Grotefeld expires January 2001 [Page 17] Raisanen, Grotefeld expires May 2001 [Page 17]
4.9 Statistics based on Type-P-One-way-Delay-Periodic-Stream 4.9 Statistics based on Type-P-One-way-Delay-Periodic-Stream
4.9.1 Statistics calculable from one sample 4.9.1 Statistics calculable from one sample
As a metric based on a sample representative of certain As a metric based on a sample representative of certain
applications, some general purpose statistics (e.g. median and applications, some general purpose statistics (e.g. median and
percentile) may be less applicable than ways to characterize the percentile) may be less applicable than ways to characterize the
range of delay values recorded during the sample metrics. range of delay values recorded during the sample metrics.
skipping to change at line 846 skipping to change at line 859
5. Security Considerations 5. Security Considerations
5.1 Denial of Service Attacks 5.1 Denial of Service Attacks
This metric generates a periodic stream of packets from one host (Src) This metric generates a periodic stream of packets from one host (Src)
to another host (Dst) through intervening networks. This metric to another host (Dst) through intervening networks. This metric
could be abused for denial of service attacks directed at Dst and/or could be abused for denial of service attacks directed at Dst and/or
the intervening network(s). the intervening network(s).
Raisanen, Grotefeld expires January 2001 [Page 18] Raisanen, Grotefeld expires May 2001 [Page 18]
Administrators of Src, Dst, and the intervening network(s) should Administrators of Src, Dst, and the intervening network(s) should
establish bilateral or multi-lateral agreements regarding the timing, establish bilateral or multi-lateral agreements regarding the timing,
size, and frequency of collection of sample metrics. Use of this size, and frequency of collection of sample metrics. Use of this
metric in excess the terms agreed between the participants MAY BE metric in excess the terms agreed between the participants MAY BE
cause for immediate rejection or discard of packets or other cause for immediate rejection or discard of packets or other
escalation procedures defined between the affected parties. escalation procedures defined between the affected parties.
5.2 User data confidentiality 5.2 User data confidentiality
This metric generates packets for a sample metric, rather than This metric generates packets for a sample metric, rather than
skipping to change at line 871 skipping to change at line 884
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 are part of a sample metric. With that knowledge at Dst packets are part of a sample metric. With that knowledge at Dst
and/or the intervening networks, it is possible to change the and/or the intervening networks, it is possible to change the
processing of the packets (e.g. increasing or decreasing delay) processing of the packets (e.g. increasing or decreasing delay)
that may distort the measured performance. It may also be that may distort the measured performance. It may also be
possible to generate additional packets that appear to be part of possible to generate additional packets that appear to be part of
the sample metric. These additional packets are likely to perturb the sample metric. These additional packets are likely to perturb
the results of the sample measurement. the results of the sample measurement.
To discourage the kind of interference mentioned above, packet
interference checks, such as cryptographic hash, MAY be used.
6. Acknowledgements 6. Acknowledgements
The authors wish to thank the chairs of the IPPM WG for comments The authors wish to thank the chairs of the IPPM WG for comments
that have made the present draft clearer and more focused. Howard that have made the present draft clearer and more focused. Howard
Stanislevic and Al Morton ahave presented useful comments and Stanislevic and Al Morton ahave presented useful comments and
questions. The authors have also built on the substantial questions. The authors have also built on the substantial
foundations laid by the authors of the framework for IP foundations laid by the authors of the framework for IP
performance [1]. performance [1].
Raisanen, Grotefeld expires May 2001 [Page 19]
7. References 7. References
[1] V.Paxson, G.Almes, J.Mahdavi, and M.Mathis: Framework for IP [1] V.Paxson, G.Almes, J.Mahdavi, and M.Mathis: Framework for IP
Performance Metrics, IETF RFC 2330, May 1998. Performance Metrics, IETF RFC 2330, May 1998.
[2] G.Almes, S.Kalidindi, and M.Zekauskas: A one-way delay metric [2] G.Almes, S.Kalidindi, and M.Zekauskas: A one-way delay metric
for IPPM, IETF RFC 2679, September 1999. for IPPM, IETF RFC 2679, September 1999.
[3] International Telecommunications Union recommendation I.380, [3] International Telecommunications Union recommendation I.380,
February 1999. February 1999.
[4] S. Bradner: Key words for use in RFCs to Indicate Requirement [4] S. Bradner: Key words for use in RFCs to Indicate Requirement
Levels, RFC 2119, March 1997. Levels, RFC 2119, March 1997.
[5] ETSI TIPHON document TS-101329-5 (to be published in July). [5] ETSI TIPHON document TS-101329-5 (to be published in July).
[6] G.Almes, S.Kalidindi, and M.Zekauskas: A round-trip delay [6] G.Almes, S.Kalidindi, and M.Zekauskas: A round-trip delay
metric for IPPM, IETF RFC 2681. metric for IPPM, IETF RFC 2681.
Raisanen, Grotefeld expires January 2001 [Page 19]
8. Authors' contact information 8. Authors' contact information
Vilho Raisanen <Vilho.Raisanen@nokia.com> Vilho Raisanen <Vilho.Raisanen@nokia.com>
P.O. Box 407 P.O. Box 407
Communication Systems Laboratory Communication Systems Laboratory
Nokia Research Center Nokia Research Center
FIN-00045 Nokia Group FIN-00045 Nokia Group
Finland Finland
Phone +358 9 4376 1 Phone +358 9 4376 1
Fax. +358 9 4376 6852 Fax. +358 9 4376 6852
Glenn Grotefeld <g.grotefeld@motorola.com> Glenn Grotefeld <g.grotefeld@motorola.com>
Motorola, Inc. Motorola, Inc.
1303 E. Algonquin Road 1303 E. Algonquin Road
4th Floor 4th Floor
Schaumburg, IL 60196 Schaumburg, IL 60196
USA USA
Phone +1 847 576-5992 Phone +1 847 576-5992
Fax +1 847 538-7455 Fax +1 847 538-7455
EXPIRES JANUARY 2001 EXPIRES May 2001
 End of changes. 

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