draft-ietf-ippm-loss-pattern-06.txt   rfc3357.txt 
IPPM Working Group Rajeev Koodli Network Working Group R. Koodli
INTERNET DRAFT Nokia Research Center Request for Comments: 3357 Nokia Research Center
5 December 2001 R. Ravikanth Category: Informational R. Ravikanth
Axiowave Axiowave
August 2002
One-way Loss Pattern Sample Metrics One-way Loss Pattern Sample Metrics
draft-ietf-ippm-loss-pattern-06.txt
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at:
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at:
http://www.ietf.org/shadow.html.
This memo provides information for the Internet community. This memo
does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.
Abstract
The Internet exhibits certain specific types of behavior (e.g.,
bursty packet loss) that can affect the performance seen by the users
as well as the operators. Previously, the focus of the IPPM had
been on specifying base metrics such as delay, loss and connectivity
under the framework described in [10]. However, specific Internet
behaviors can also be captured under the umbrella of IPPM framework,
specifying new concepts while reusing existing guidelines as much as
possible. This document defines metrics derived from the previously
specified base metrics to capture loss patterns experienced by
streams of packets on the Internet.
Contents
Status of This Memo i
Abstract i Status of this Memo
1. Introduction 2
2. Terminology 2
3. The Approach 2 This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
4. Basic Definitions 3 Copyright Notice
5. Definitions for Samples of One-way Loss Distance, and One-way Copyright (C) The Internet Society (2002). All Rights Reserved.
Loss Period 4
5.1. Metric Names . . . . . . . . . . . . . . . . . . . . . . 4
5.1.1. Type-P-One-Way-Loss-Distance-Stream . . . . . . . 4
5.1.2. Type-P-One-Way-Loss-Period-Stream . . . . . . . . 4
5.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 4
5.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . 4
5.3.1. Type-P-One-Way-Loss-Distance-Stream . . . . . . . 4
5.3.2. Type-P-One-Way-Loss-Period-Stream . . . . . . . . 4
5.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 5
5.4.1. Type-P-One-Way-Loss-Distance-Stream . . . . . . . 5
5.4.2. Type-P-One-Way-Loss-Period-Stream . . . . . . . . 5
5.4.3. Examples . . . . . . . . . . . . . . . . . . . . 5
5.5. Methodologies . . . . . . . . . . . . . . . . . . . . . . 6
5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 7
5.7. Sampling Considerations . . . . . . . . . . . . . . . . . 7
5.8. Errors and Uncertainties . . . . . . . . . . . . . . . . 7
6. Statistics 8 Abstract
6.1. Type-P-One-Way-Loss-Noticeable-Rate . . . . . . . . . . . 8
6.2. Type-P-One-Way-Loss-Period-Total . . . . . . . . . . . . 8
6.3. Type-P-One-Way-Loss-Period-Lengths . . . . . . . . . . . 9
6.4. Type-P-One-Way-Inter-Loss-Period-Lengths . . . . . . . . 9
6.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Security Considerations: 10 Using the base loss metric defined in RFC 2680, this document defines
two derived metrics "loss distance" and "loss period", and the
associated statistics that together capture loss patterns experienced
by packet streams on the Internet. The Internet exhibits certain
specific types of behavior (e.g., bursty packet loss) that can affect
the performance seen by the users as well as the operators. The loss
pattern or loss distribution is a key parameter that determines the
performance observed by the users for certain real-time applications
such as packet voice and video. For the same loss rate, two
different loss distributions could potentially produce widely
different perceptions of performance.
8. IANA Considerations 11 Table of Contents
9. Acknowledgements 11 1. Introduction 3
2. Terminology 3
3. The Approach 3
4. Basic Definitions 4
5. Definitions for Samples of One-way Loss Distance, and One-way
Loss Period 5
5.1. Metric Names . . . . . . . . . . . . . . . . . . . . . . 5
5.1.1. Type-P-One-Way-Loss-Distance-Stream . . . . . . . 5
5.1.2. Type-P-One-Way-Loss-Period-Stream . . . . . . . . 5
5.2. Metric Parameters . . . . . . . . . . . . . . . . . . . . 5
5.3. Metric Units . . . . . . . . . . . . . . . . . . . . . . 5
5.3.1. Type-P-One-Way-Loss-Distance-Stream . . . . . . . 5
5.3.2. Type-P-One-Way-Loss-Period-Stream . . . . . . . . 5
5.4. Definitions . . . . . . . . . . . . . . . . . . . . . . . 6
5.4.1. Type-P-One-Way-Loss-Distance-Stream . . . . . . . 6
5.4.2. Type-P-One-Way-Loss-Period-Stream . . . . . . . . 6
5.4.3. Examples . . . . . . . . . . . . . . . . . . . . 6
5.5. Methodologies . . . . . . . . . . . . . . . . . . . . . . 7
5.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . 8
5.7. Sampling Considerations . . . . . . . . . . . . . . . . . 8
5.8. Errors and Uncertainties . . . . . . . . . . . . . . . . 8
6. Statistics 9
6.1. Type-P-One-Way-Loss-Noticeable-Rate . . . . . . . . . . . 9
6.2. Type-P-One-Way-Loss-Period-Total . . . . . . . . . . . . 9
6.3. Type-P-One-Way-Loss-Period-Lengths . . . . . . . . . . . 10
6.4. Type-P-One-Way-Inter-Loss-Period-Lengths . . . . . . . . 10
6.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations 11
7.1. Denial of Service Attacks . . . . . . . . . . . . . . . . 12
7.2. Privacy / Confidentiality . . . . . . . . . . . . . . . . 12
7.3. Integrity . . . . . . . . . . . . . . . . . . . . . . . . 12
8. IANA Considerations 12
9. Acknowledgements 12
10. Normative References 12
11. Informative References 13
Authors' Addresses 14
Full Copyright Statement 15
Addresses 13 1. Introduction
1. Introduction
In certain real-time applications (such as packet voice and In certain real-time applications (such as packet voice and video),
video), the loss pattern or loss distribution is a key parameter the loss pattern or loss distribution is a key parameter that
that determines the performance observed by the users. For the determines the performance observed by the users. For the same loss
same loss rate, two different loss distributions could potentially rate, two different loss distributions could potentially produce
produce widely different perceptions of performance. The impact widely different perceptions of performance. The impact of loss
of loss pattern is also extremely important for non-real-time pattern is also extremely important for non-real-time applications
applications that use an adaptive protocol such as TCP. Refer that use an adaptive protocol such as TCP. Refer to [4], [5], [6],
to [2], [3], [5], [12] for evidence as to the importance and [11] for evidence as to the importance and existence of loss
existence of loss burstiness and its effect on packet voice and video burstiness and its effect on packet voice and video applications.
applications.
In this document, we propose two derived metrics, called "loss Previously, the focus of the IPPM had been on specifying base metrics
distance" and "loss period", with associated statistics, to capture such as delay, loss and connectivity under the framework described in
packet loss patterns. The loss period metric captures the frequency RFC 2330. However, specific Internet behaviors can also be captured
and length (burstiness) of loss once it starts, and the loss under the umbrella of the IPPM framework, specifying new concepts
distance metric captures the spacing between the loss periods. It is while reusing existing guidelines as much as possible. In this
important to note that these metrics are derived based on the base document, we propose two derived metrics, called "loss distance" and
metric Type-P-One-Way-packet-Loss. "loss period", with associated statistics, to capture packet loss
patterns. The loss period metric captures the frequency and length
(burstiness) of loss once it starts, and the loss distance metric
captures the spacing between the loss periods. It is important to
note that these metrics are derived based on the base metric Type-P-
One-Way-packet-Loss.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and
"silently ignore" in this document are to be interpreted as described "silently ignore" in this document are to be interpreted as described
in RFC 2119 [4]. in BCP 14, RFC 2119 [2].
3. The Approach 3. The Approach
This document closely follows the guidelines specified in [10]. This document closely follows the guidelines specified in [3].
Specifically, the concepts of singleton, sample, statistic, Specifically, the concepts of singleton, sample, statistic,
measurement principles, Type-P packets, as well as standard-formed measurement principles, Type-P packets, as well as standard-formed
packets all apply. However, since the draft proposes to capture packets all apply. However, since the document proposes to capture
specific Internet behaviors, modifications to the sampling process specific Internet behaviors, modifications to the sampling process
MAY be needed. Indeed, this is mentioned in [1], where it is MAY be needed. Indeed, this is mentioned in [1], where it is noted
noted that alternate sampling procedures may be useful depending that alternate sampling procedures may be useful depending on
on specific circumstances. This draft proposes that the specific specific circumstances. This document proposes that the specific
behaviors be captured as "derived" metrics from the base metrics the behaviors be captured as "derived" metrics from the base metrics the
behaviors are related to. The reasons for adopting this position are behaviors are related to. The reasons for adopting this position are
the following: the following:
- it provides consistent usage of singleton metric definition for - it provides consistent usage of singleton metric definition for
different behaviors (e.g., a single definition of packet loss is different behaviors (e.g., a single definition of packet loss is
needed for capturing burst of losses, 'm out of n' losses etc.) needed for capturing burst of losses, 'm out of n' losses etc.)
- it allows re-use of the methodologies specified for the singleton - it allows re-use of the methodologies specified for the singleton
metric with modifications whenever necessary metric with modifications whenever necessary
- it clearly separates few base metrics from many Internet - it clearly separates few base metrics from many Internet behaviors
behaviors
Following the guidelines in [10], this translates to deriving Following the guidelines in [3], this translates to deriving sample
sample metrics from the respective singletons. The process metrics from the respective singletons. The process of deriving
of deriving sample metrics from the singletons is specified sample metrics from the singletons is specified in [3], [1], and
in [10], [1], and others. others.
In the following sections, we apply this approach to a particular In the following sections, we apply this approach to a particular
Internet behavior, namely the packet loss process. Internet behavior, namely the packet loss process.
4. Basic Definitions 4. Basic Definitions
Sequence number: Consecutive packets in a time series sample Sequence number: Consecutive packets in a time series sample are
are given sequence numbers that are consecutive given sequence numbers that are consecutive
integers. This document does not specify exactly integers. This document does not specify exactly
how to associate sequence numbers with packets. The how to associate sequence numbers with packets. The
sequence numbers could be contained within test sequence numbers could be contained within test
packets themselves, or they could be derived through packets themselves, or they could be derived through
post-processing of the sample. post-processing of the sample.
Bursty loss: The loss involving consecutive packets of a stream. Bursty loss: The loss involving consecutive packets of a stream.
Loss Distance: The difference in sequence numbers of two Loss Distance: The difference in sequence numbers of two successively
successively lost packets which may or may not be lost packets which may or may not be separated by
separated by successfully received packets. successfully received packets.
Example: In a packet stream, the packet with sequence number 20 Example: In a packet stream, the packet with sequence number 20 is
is considered lost, followed by the packet with considered lost, followed by the packet with sequence number
sequence number 50. The loss distance is 30. 50. The loss distance is 30.
Loss period: Let P_i be the i'th packet. Define f(P_i) = 1 if P_i Loss period: Let P_i be the i'th packet. Define f(P_i) = 1 if P_i is
is lost, 0 otherwise. Then, a loss period begins if lost, 0 otherwise. Then, a loss period begins if
f(P_i) = 1 and f(P_(i-1)) = 0 f(P_i) = 1 and f(P_(i-1)) = 0
Example: Consider the following sequence of lost (denoted by x) Example: Consider the following sequence of lost (denoted by x) and
and received (denoted by r) packets. received (denoted by r) packets.
r r r x r r x x x r x r r x x x r r r x r r x x x r x r r x x x
Then, with `i' assigned as follows, Then, with `i' assigned as follows,
1 1 1 1 1 1 1 1 1 1 1 1
i: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 i: 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
f(P_i) is,
f(P_i): 0 0 0 1 0 0 1 1 1 0 1 0 0 1 1 1 f(P_i) is,
and there are four loss periods in the above sequence f(P_i): 0 0 0 1 0 0 1 1 1 0 1 0 0 1 1 1
beginning at P_3, P_6, P_10, and P_13.
5. Definitions for Samples of One-way Loss Distance, and One-way and there are four loss periods in the above sequence beginning at
Loss Period P_3, P_6, P_10, and P_13.
5.1. Metric Names 5. Definitions for Samples of One-way Loss Distance, and One-way Loss
Period
5.1.1. Type-P-One-Way-Loss-Distance-Stream 5.1. Metric Names
5.1.2. Type-P-One-Way-Loss-Period-Stream 5.1.1. Type-P-One-Way-Loss-Distance-Stream
5.2. Metric Parameters 5.1.2. Type-P-One-Way-Loss-Period-Stream
Src, the IP address of a host 5.2. Metric Parameters
Dst, the IP address of a host Src, the IP address of a host
T0, a time Dst, the IP address of a host
Tf, a time T0, a time
lambda, a rate of any sampling method chosen in reciprocal of Tf, a time
seconds
5.3. Metric Units lambda, a rate of any sampling method chosen in reciprocal of
seconds
5.3.1. Type-P-One-Way-Loss-Distance-Stream 5.3. Metric Units
A sequence of pairs of the form <loss distance, loss>, where 5.3.1. Type-P-One-Way-Loss-Distance-Stream
loss is derived from the sequence of <time, loss> in [1], and loss
distance is either zero or a positive integer.
5.3.2. Type-P-One-Way-Loss-Period-Stream A sequence of pairs of the form <loss distance, loss>, where loss is
derived from the sequence of <time, loss> in [1], and loss distance
is either zero or a positive integer.
A sequence of pairs of the form <loss period, loss>, where loss is 5.3.2. Type-P-One-Way-Loss-Period-Stream
A sequence of pairs of the form <loss period, loss>, where loss is
derived from the sequence of <time, loss> in [1], and loss period is derived from the sequence of <time, loss> in [1], and loss period is
an integer. an integer.
5.4. Definitions 5.4. Definitions
5.4.1. Type-P-One-Way-Loss-Distance-Stream 5.4.1. Type-P-One-Way-Loss-Distance-Stream
When a packet is considered lost (using the definition in [1]), When a packet is considered lost (using the definition in [1]), we
we look at its sequence number and compare it with that of the look at its sequence number and compare it with that of the
previously lost packet. The difference is the loss distance between previously lost packet. The difference is the loss distance between
the lost packet and the previously lost packet. The sample would the lost packet and the previously lost packet. The sample would
consist of <loss distance, loss> pairs. This definition assumes that consist of <loss distance, loss> pairs. This definition assumes that
sequence numbers of successive test packets increase monotonically by sequence numbers of successive test packets increase monotonically by
one. The loss distance associated with the very first packet loss is one. The loss distance associated with the very first packet loss is
considered to be zero. considered to be zero.
The sequence number of a test packet can be derived from the The sequence number of a test packet can be derived from the
timeseries sample collected by performing the loss measurement timeseries sample collected by performing the loss measurement
according to the methodology in [1]. For example, if a loss sample according to the methodology in [1]. For example, if a loss sample
consists of <T0,0>, <T1,0>, <T2,1>, <T3,0>, <T4,0>, the sequence consists of <T0,0>, <T1,0>, <T2,1>, <T3,0>, <T4,0>, the sequence
numbers of the five test packets sent at T0, T1, T2, T3, and T4 can numbers of the five test packets sent at T0, T1, T2, T3, and T4 can
be 0, 1, 2, 3 and 4 respectively, or 100, 101, 102, 103 and 104 be 0, 1, 2, 3 and 4 respectively, or 100, 101, 102, 103 and 104
respectively, etc. respectively, etc.
5.4.2. Type-P-One-Way-Loss-Period-Stream 5.4.2. Type-P-One-Way-Loss-Period-Stream
We start a counter 'n' at an initial value of zero. This We start a counter 'n' at an initial value of zero. This counter is
counter is incremented by one each time a lost packet satisfies the incremented by one each time a lost packet satisfies the definition
definition outlined in 4. The metric is defined as <loss period, outlined in 4. The metric is defined as <loss period, loss> where
loss> where "loss" is derived from the sequence of <time, loss> in "loss" is derived from the sequence of <time, loss> in Type-P-One-
Type-P-One-Way-Loss-Stream [1], and loss period is set to zero when Way-Loss-Stream [1], and loss period is set to zero when "loss" is
"loss" is zero in Type-P-One-Way-Loss-Stream, and loss period is set zero in Type-P-One-Way-Loss-Stream, and loss period is set to 'n'
to 'n' (above) when "loss" is one in Type-P-One-Way-Loss-Stream. (above) when "loss" is one in Type-P-One-Way-Loss-Stream.
Essentially, when a packet is lost, the current value of "n" Essentially, when a packet is lost, the current value of "n"
indicates the loss period to which this packet belongs. For a packet indicates the loss period to which this packet belongs. For a packet
that is received successfully, the loss period is defined to be zero. that is received successfully, the loss period is defined to be zero.
5.4.3. Examples 5.4.3. Examples
Let the following set of pairs represent a Type-P-One-Way-Loss-Stream. Let the following set of pairs represent a Type-P-One-Way-Loss-
Stream.
{<T1,0>,<T2,1>,<T3,0>,<T4,0>,<T5,1>,<T6,0>,<T7,1>,<T8,0>,<T9,1>,<T10,1>} {<T1,0>,<T2,1>,<T3,0>,<T4,0>,<T5,1>,<T6,0>,<T7,1>,<T8,0>,
<T9,1>,<T10,1>}
where T1, T2,..,T10 are in increasing order. where T1, T2,..,T10 are in increasing order.
Packets sent at T2, T5, T7, T9, T10 are lost. The two derived Packets sent at T2, T5, T7, T9, T10 are lost. The two derived
metrics can be obtained from this sample as follows. metrics can be obtained from this sample as follows.
(i) Type-P-One-Way-Loss-Distance-Stream: (i) Type-P-One-Way-Loss-Distance-Stream:
Since packet 2 is the first lost packet, the associated loss Since packet 2 is the first lost packet, the associated loss distance
distance is zero. For the next lost packet (packet 5), loss distance is zero. For the next lost packet (packet 5), loss distance is 5-2
is 5-2 or 3. Similarly, for the remaining lost packets (packets or 3. Similarly, for the remaining lost packets (packets 7, 9, and
7, 9, and 10) their loss distances are 2, 2, and 1 respectively. 10) their loss distances are 2, 2, and 1 respectively. Therefore,
Therefore, the Type-P-One-Way-Loss-Distance-Stream is: the Type-P-One-Way-Loss-Distance-Stream is:
{<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>} {<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>}
(ii) The Type-P-One-Way-Loss-Period-Stream: (ii) The Type-P-One-Way-Loss-Period-Stream:
The packet 2 sets the counter 'n' to 1, which is incremented The packet 2 sets the counter 'n' to 1, which is incremented by one
by one for packets 5, 7 and 9 according to the definition in 4. for packets 5, 7 and 9 according to the definition in 4. However,
However, for packet 10, the counter remains at 4, again satisfying for packet 10, the counter remains at 4, again satisfying the
the definition in 4. Thus, the Type-P-One-Way-Loss-Period-Stream is: definition in 4. Thus, the Type-P-One-Way-Loss-Period-Stream is:
{<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>} {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}
5.5. Methodologies 5.5. Methodologies
The same methodology outlined in [1] can be used to conduct the The same methodology outlined in [1] can be used to conduct the
sample experiments. A synopsis is listed below. sample experiments. A synopsis is listed below.
Generally, for a given Type-P, one possible methodology would Generally, for a given Type-P, one possible methodology would proceed
proceed as follows: as follows:
- Arrange that Src and Dst have clocks that are synchronized with - Assume that Src and Dst have clocks that are synchronized with
each other. The degree of synchronization is a parameter of the each other. The degree of synchronization is a parameter of the
methodology, and depends on the threshold used to determine loss methodology, and depends on the threshold used to determine loss
(see below). (see below).
- At the Src host, select Src and Dst IP addresses, and form a test - At the Src host, select Src and Dst IP addresses, and form a test
packet of Type-P with these addresses. packet of Type-P with these addresses.
- At the Dst host, arrange to receive the packet. - At the Dst host, arrange to receive the packet.
- At the Src host, place a timestamp in the prepared Type-P packet, - At the Src host, place a timestamp in the prepared Type-P packet,
and send it towards Dst. and send it towards Dst.
- If the packet arrives within a reasonable period of time, the - If the packet arrives within a reasonable period of time, the
one-way packet-loss is taken to be zero. one-way packet-loss is taken to be zero.
- If the packet fails to arrive within a reasonable period of - If the packet fails to arrive within a reasonable period of time,
time, the one-way packet-loss is taken to be one. Note that the the one-way packet-loss is taken to be one. Note that the
threshold of "reasonable" here is a parameter of the methodology. threshold of "reasonable" here is a parameter of the methodology.
5.6. Discussion 5.6. Discussion
The Loss-Distance-Stream metric allows one to study the separation The Loss-Distance-Stream metric allows one to study the separation
between packet losses. This could be useful in determining a "spread between packet losses. This could be useful in determining a "spread
factor" associated with the packet loss rate. In conjunction, the factor" associated with the packet loss rate. In conjunction, the
Loss-Period-Stream metric allows the study of loss burstiness for Loss-Period-Stream metric allows the study of loss burstiness for
each occurrence of loss. A single loss period of length 'n' can each occurrence of loss. A single loss period of length 'n' can
account for a significant portion of the overall loss rate. Note account for a significant portion of the overall loss rate. Note
that it is possible to measure distance between loss bursts separated that it is possible to measure distance between loss bursts separated
by one or more successfully received packets. (Refer to Sections 6.4 by one or more successfully received packets. (Refer to Sections 6.4
and 6.5). and 6.5).
5.7. Sampling Considerations 5.7. Sampling Considerations
The proposed metrics can be used independent of the particular The proposed metrics can be used independent of the particular
sampling method used. We note that Poisson sampling may not sampling method used. We note that Poisson sampling may not yield
yield appropriate values for these metrics for certain real-time appropriate values for these metrics for certain real-time
applications such as voice over IP, as well as to TCP-based applications such as voice over IP, as well as to TCP-based
applications. For real-time applications, it may be more appropriate applications. For real-time applications, it may be more appropriate
to use the ON-OFF [11] model, in which an ON period starts with to use the ON-OFF [10] model, in which an ON period starts with a
certain probability 'p', during which certain number of packets certain probability 'p', during which a certain number of packets are
are transmitted with mean 'lambda-on' according to geometric transmitted with mean 'lambda-on' according to geometric distribution
distribution and an OFF period starts with probability '1-p' and and an OFF period starts with probability '1-p' and lasts for a
lasts for a period of time based on exponential distribution with period of time based on exponential distribution with rate 'lambda-
rate 'lambda-off'. off'.
For TCP-based applications, one may use the model proposed in [7]. For TCP-based applications, one may use the model proposed in [8].
See [8] for an application of the model. See [9] for an application of the model.
5.8. Errors and Uncertainties 5.8. Errors and Uncertainties
The measurement aspects, including the packet size, loss The measurement aspects, including the packet size, loss threshold,
threshold, type of the test machine chosen etc, invariably influence type of the test machine chosen etc, invariably influence the packet
the packet loss metric itself and hence the derived metrics described loss metric itself and hence the derived metrics described in this
in this document. Thus, when making assessment of the results document. Thus, when making an assessment of the results pertaining
pertaining to the metrics outlined in this document, attention must to the metrics outlined in this document, attention must be paid to
be paid to these matters. See [1] for a detailed consideration of these matters. See [1] for a detailed consideration of errors and
errors and uncertainties regarding the measurement of base packet uncertainties regarding the measurement of base packet loss metric.
loss metric.
6. Statistics 6. Statistics
6.1. Type-P-One-Way-Loss-Noticeable-Rate 6.1. Type-P-One-Way-Loss-Noticeable-Rate
Define loss of a packet to be "noticeable" [6] if the distance Define loss of a packet to be "noticeable" [7] if the distance
between the lost packet and the previously lost packet is no greater between the lost packet and the previously lost packet is no greater
than delta, a positive integer, where delta is the "loss constraint". than delta, a positive integer, where delta is the "loss constraint".
Example: Let delta = 99. Let us assume that packet 50 is lost Example: Let delta = 99. Let us assume that packet 50 is lost
followed by a bursty loss of length 3 starting from packet 125. All followed by a bursty loss of length 3 starting from packet 125. All
the three losses starting from packet 125 are noticeable. the three losses starting from packet 125 are noticeable.
Given a Type-P-One-Way-Loss-Distance-Stream, this statistic can be Given a Type-P-One-Way-Loss-Distance-Stream, this statistic can be
computed simply as the number of losses that violate some constraint computed simply as the number of losses that violate some constraint
delta, divided by the number of losses. (Alternatively, it can also delta, divided by the number of losses. (Alternatively, it can also
be defined as the number of "noticeable losses" to the number of be defined as the number of "noticeable losses" to the number of
successfully received packets). This statistic is useful when the successfully received packets). This statistic is useful when the
actual distance between successive losses is important. For example, actual distance between successive losses is important. For example,
many multimedia codecs can sustain losses by "concealing" the effect many multimedia codecs can sustain losses by "concealing" the effect
of loss by making use of past history information. Their ability to of loss by making use of past history information. Their ability to
do so degrades with poor history resulting from losses separated by do so degrades with poor history resulting from losses separated by
close distances. By choosing delta based on this sensitivity, one close distances. By choosing delta based on this sensitivity, one
can measure how "noticeable" a loss might be for quality purposes. can measure how "noticeable" a loss might be for quality purposes.
The noticeable loss requires a certain "spread factor" for losses The noticeable loss requires a certain "spread factor" for losses in
in the timeseries. In the above example where loss constraint is the timeseries. In the above example where loss constraint is equal
equal to 99, a loss rate of one percent with a spread of 100 between to 99, a loss rate of one percent with a spread of 100 between losses
losses (e.g., 100, 200, 300, 400, 500 out of 500 packets) may be more (e.g., 100, 200, 300, 400, 500 out of 500 packets) may be more
desirable for some applications compared to the same loss rate with a desirable for some applications compared to the same loss rate with a
spread that violates the loss constraint (e.g., 100, 175, 275, 290, spread that violates the loss constraint (e.g., 100, 175, 275, 290,
400: losses occurring at 175 and 290 violate delta = 99). 400: losses occurring at 175 and 290 violate delta = 99).
6.2. Type-P-One-Way-Loss-Period-Total 6.2. Type-P-One-Way-Loss-Period-Total
This represents the total number of loss periods, and can be This represents the total number of loss periods, and can be derived
derived from the loss period metric Type-P-One-Way-Loss-Period-Stream from the loss period metric Type-P-One-Way-Loss-Period-Stream as
as follows: follows:
Type-P-One-Way-Loss-Period-Total = maximum value of the first Type-P-One-Way-Loss-Period-Total = maximum value of the first entry
entry of the set of pairs, <loss period, loss>, representing the loss of the set of pairs, <loss period, loss>, representing the loss
metric Type-P-One-Way-Loss-Period-Stream. metric Type-P-One-Way-Loss-Period-Stream.
Note that this statistic does not describe the duration of each Note that this statistic does not describe the duration of each loss
loss period itself. If this statistic is large, it does not mean period itself. If this statistic is large, it does not mean that the
that the losses are more spread out than they are otherwise; one losses are more spread out than they are otherwise; one or more loss
or more loss periods may include bursty losses. This statistic is periods may include bursty losses. This statistic is generally
generally useful in gathering first order of approximation of loss useful in gathering first order approximation of loss spread.
spread.
6.3. Type-P-One-Way-Loss-Period-Lengths 6.3. Type-P-One-Way-Loss-Period-Lengths
This statistic is a sequence of pairs <loss period, This statistic is a sequence of pairs <loss period, length>, with the
length>, with the "loss period" entry ranging from 1 - "loss period" entry ranging from 1 - Type-P-One-Way-Loss-Period-
Type-P-One-Way-Loss-Period-Total. Thus the total number of Total. Thus the total number of pairs in this statistic equals
pairs in this statistic equals Type-P-One-Way-Loss-Period-Total. In Type-P-One-Way-Loss-Period-Total. In each pair, the "length" is
each pair, the "length" is obtained by counting the number of pairs, obtained by counting the number of pairs, <loss period, loss>, in the
<loss period, loss>, in the metric Type-P-One-Way-Loss-Period-Stream metric Type-P-One-Way-Loss-Period-Stream which have their first entry
which have first entry equal to "loss period." equal to "loss period."
Since this statistic represents the number of packets lost in each Since this statistic represents the number of packets lost in each
loss period, it is an indicator of burstiness of each loss period. loss period, it is an indicator of burstiness of each loss period.
In conjunction with loss-period-total statistic, this statistic is In conjunction with loss-period-total statistic, this statistic is
generally useful in observing which loss periods are potentially more generally useful in observing which loss periods are potentially more
influential than others from a quality perspective. influential than others from a quality perspective.
6.4. Type-P-One-Way-Inter-Loss-Period-Lengths 6.4. Type-P-One-Way-Inter-Loss-Period-Lengths
This statistic measures distance between successive loss This statistic measures distance between successive loss periods. It
periods. It takes the form of a set of pairs <loss period, takes the form of a set of pairs <loss period, inter-loss-period-
inter-loss-period-length>, with the "loss period" entry ranging from length>, with the "loss period" entry ranging from 1 - Type-P-One-
1 - Type-P-One-Way-Loss-Period-Total, and "inter-loss-period-length" Way-Loss-Period-Total, and "inter-loss-period-length" is the loss
is the loss distance between the last packet considered lost in "loss distance between the last packet considered lost in "loss period"
period" 'i-1', and the first packet considered lost in "loss period" 'i-1', and the first packet considered lost in "loss period" 'i',
'i', where 'i' ranges from 2 to Type-P-One-Way-Loss-Period-Total. where 'i' ranges from 2 to Type-P-One-Way-Loss-Period-Total. The
The "inter-loss-period-length" associated with the first "loss "inter-loss-period-length" associated with the first "loss period" is
period" is defined to be zero. defined to be zero.
This statistic allows one to consider, for example, two loss This statistic allows one to consider, for example, two loss periods
periods each of length greater than one (implying loss burst), but each of length greater than one (implying loss burst), but separated
separated by a distance of 2 to belong to the same loss burst if such by a distance of 2 to belong to the same loss burst if such a
a consideration is deemed useful. When the Inter-Loss-Period-Length consideration is deemed useful. When the Inter-Loss-Period-Length
between two bursty loss periods is smaller, it could affect the loss between two bursty loss periods is smaller, it could affect the loss
concealing ability of multimedia codecs since there is relatively concealing ability of multimedia codecs since there is relatively
smaller history. When it is larger, an application may be able to smaller history. When it is larger, an application may be able to
rebuild its history which could dampen the effect of an impending rebuild its history which could dampen the effect of an impending
loss (period). loss (period).
6.5. Examples 6.5. Examples
We continue with the same example as in Section 5.4.3. The three We continue with the same example as in Section 5.4.3. The three
statistics defined above will have the following values. statistics defined above will have the following values.
- Let delta = 2. In Type-P-One-Way-Loss-Distance-Stream - Let delta = 2. In Type-P-One-Way-Loss-Distance-Stream
{<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>}, {<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>},
there are 3 loss distances that violate the delta of 2. Thus, there are 3 loss distances that violate the delta of 2. Thus,
Type-P-One-Way-Loss-Noticeable-Rate = 3/5 ((number of noticeable
Type-P-One-Way-Loss-Noticeable-Rate = 3/5 ((number of noticeable losses)/(number of total losses))
losses)/(number of total losses))
- In Type-P-One-Way-Loss-Period-Stream - In Type-P-One-Way-Loss-Period-Stream
{<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>},
the largest of the first entry in the sequence of <loss the largest of the first entry in the sequence of <loss
period,loss> pairs is 4. Thus, period,loss> pairs is 4. Thus,
Type-P-One-Way-Loss-Period-Total = 4 Type-P-One-Way-Loss-Period-Total = 4
- In Type-P-One-Way-Loss-Period-Stream - In Type-P-One-Way-Loss-Period-Stream
{<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>},
the lengths of individual loss periods are 1, 1, 1 and 2 the lengths of individual loss periods are 1, 1, 1 and 2
respectively. Thus, respectively. Thus,
Type-P-One-Way-Loss-Period-Lengths = Type-P-One-Way-Loss-Period-Lengths =
{<1,1>,<2,1>,<3,1>,<4,2>} {<1,1>,<2,1>,<3,1>,<4,2>}
- In Type-P-One-Way-Loss-Period-Stream - In Type-P-One-Way-Loss-Period-Stream
{<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>},
the loss periods 1 and 2 are separated by 3 (5-2), loss periods the loss periods 1 and 2 are separated by 3 (5-2), loss periods 2
2 and 3 are separated by 2 (7-5), and 3 and 4 are separated by 2 and 3 are separated by 2 (7-5), and 3 and 4 are separated by 2
(9-7). Thus, (9-7). Thus, Type-P-One-Way-Inter-Loss-Period-Lengths =
Type-P-One-Way-Inter-Loss-Period-Lengths =
{<1,0>,<2,3>,<3,2>,<4,2>} {<1,0>,<2,3>,<3,2>,<4,2>}
7. Security Considerations: 7. Security Considerations
Since this draft proposes sample metrics based on the base loss
metric defined in [1], it inherits the security considerations
mentioned in [1].
Conducting Internet measurements raises both security and privacy Conducting Internet measurements raises both security and privacy
concerns. This document does not specify a particular implementation concerns. This document does not specify a particular implementation
of metrics, so it does not directly affect the security of the of metrics, so it does not directly affect the security of the
Internet nor of applications which run on the Internet. However, Internet nor of applications which run on the Internet. However,
implementations of these metrics must be mindful of security and implementations of these metrics must be mindful of security and
privacy concerns. privacy concerns.
The derived sample metrics in this document are based on the loss The derived sample metrics in this document are based on the loss
metric defined in RFC-2680 [1], and thus they inherit the security metric defined in RFC 2680 [1], and thus they inherit the security
considerations of that document. The reader should consult [1] for a considerations of that document. The reader should consult [1] for a
more detailed treatment of security considerations. more detailed treatment of security considerations. Nevertheless,
there are a few things to highlight.
Nevertheless, there are a few things to highlight. First, 7.1. Denial of Service Attacks
the lambda specified in the Type-P-Loss-Distance-Stream and
Type-P-Loss-Period-Stream controls the rate at which test packets
are sent, and therefore if it is set inappropriately large could
perturb the network under test, cause congestion, or at worst be a
denial-of-service attack to the network under test.
Second, privacy of user data is not a concern, since the The lambda specified in the Type-P-Loss-Distance-Stream and Type-P-
underlying metric is intended to be implemented using test packets Loss-Period-Stream controls the rate at which test packets are sent,
that contain no user information. Even if packets contained user and therefore if it is set inappropriately large, it could perturb
information, the derived metrics do not release data sent by the the network under test, cause congestion, or at worst be a denial-
user. Third, the results could be perturbed by attempting to corrupt of-service attack to the network under test. Legitimate measurements
or disrupt the underlying stream, for example adding extra packets must have their parameters selected carefully in order to avoid
that look just like test packets. interfering with normal traffic in the network.
In general, legitimate measurements must have their parameters 7.2. Privacy / Confidentiality
selected carefully in order to avoid interfering with normal traffic
in the network. Such measurements should also be authorized and
authenticated in some way so that attacks can be identified and
intercepted.
8. IANA Considerations Privacy of user data is not a concern, since the underlying metric is
intended to be implemented using test packets that contain no user
information. Even if packets contained user information, the derived
metrics do not release data sent by the user.
Since this document does not define a specific protocol, nor does 7.3. Integrity
it define any well-known values, there are no IANA considerations for
Results could be perturbed by attempting to corrupt or disrupt the
underlying stream, for example adding extra packets that look just
like test packets. To ensure that test packets are valid and have
not been altered during transit, packet authentication and integrity
checks, such as a signed cryptographic hash, MAY be used.
8. IANA Considerations
Since this document does not define a specific protocol, nor does it
define any well-known values, there are no IANA considerations for
this document. this document.
9. Acknowledgements 9. Acknowledgements
Matt Zekauskas provided insightful feedback and the text for the Matt Zekauskas provided insightful feedback and the text for the
Security Considerations section. We sincerely thank him for his Security Considerations section. Merike Kao helped revising the
painstaking review and for supporting this work along with Merike Security Considerations and the Abstract to conform with RFC
Kaeo. Thanks to Guy Almes for encouraging the work, and Vern Paxson guidelines. We thank both of them. Thanks to Guy Almes for
for the comments during the IETF meetings. Thanks to Steve Glass for encouraging the work, and Vern Paxson for the comments during the
making the presentation at the Oslo meeting. IETF meetings. Thanks to Steve Glass for making the presentation at
the Oslo meeting.
References 10. Normative References
[1] G. Almes and S. Kalindindi and M. Zekauskas, "A One-way Packet [1] Almes, G., Kalindindi, S. and M. Zekauskas, "A One-way Packet
Loss Metric for IPPM", RFC 2680, September 1999. Loss Metric for IPPM", RFC 2680, September 1999.
[2] J.-C. Bolot and A. vega Garcia, "The case for FEC-based error [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for
IP Performance Metrics", RFC 2330, May 1998.
11. Informative References
[4] J.-C. Bolot and A. vega Garcia, "The case for FEC-based error
control for Packet Audio in the Internet", ACM Multimedia control for Packet Audio in the Internet", ACM Multimedia
Systems, 1997. Systems, 1997.
[3] M. S. Borella, D. Swider, S. Uludag, and G. B. Brewster, [5] M. S. Borella, D. Swider, S. Uludag, and G. B. Brewster,
"Internet Packet Loss: Measurement and Implications for "Internet Packet Loss: Measurement and Implications for End-
End-to-End QoS," Proceedings, International Conference on to-End QoS," Proceedings, International Conference on Parallel
Parallel Processing, August 1998. Processing, August 1998.
[4] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels," RFC 2119, Internet Engineering Task Force, March 1997.
[5] M. Handley, "An examination of MBONE performance", Technical [6] M. Handley, "An examination of MBONE performance", Technical
Report, USC/ISI, ISI/RR-97-450, July 1997 Report, USC/ISI, ISI/RR-97-450, July 1997
[6] R. Koodli, "Scheduling Support for Multi-tier Quality of [7] R. Koodli, "Scheduling Support for Multi-tier Quality of Service
Service in Continuous Media Applications", PhD dissertation, in Continuous Media Applications", PhD dissertation, Electrical
Electrical and Computer Engineering Department, University of and Computer Engineering Department, University of
Massachusetts, Amherst, MA 01003, September 1997. Massachusetts, Amherst, MA 01003, September 1997.
[7] J. Padhye, V. Firoiu, J. Kurose and D. Towsley, "Modeling TCP [8] J. Padhye, V. Firoiu, J. Kurose and D. Towsley, "Modeling TCP
throughput: a simple model and its empirical validation", in throughput: a simple model and its empirical validation", in
Proceedings of SIGCOMM'98, 1998. Proceedings of SIGCOMM'98, 1998.
[8] J. Padhye, J. Kurose, D. Towsley and R. Koodli, "A TCP-friendly [9] J. Padhye, J. Kurose, D. Towsley and R. Koodli, "A TCP-friendly
rate adjustment protocol for continuous media flows over rate adjustment protocol for continuous media flows over best-
best-effort networks", short paper presentation in ACM effort networks", short paper presentation in ACM SIGMETRICS'99.
SIGMETRICS'99. Available as Umass Computer Science tech report Available as Umass Computer Science tech report from
from ftp://gaia.cs.umass.edu/pub/Padhye98-tcp-friendly-TR.ps.gz ftp://gaia.cs.umass.edu/pub/Padhye98-tcp-friendly-TR.ps.gz
[9] V. Paxson, "End-to-end Internet packet dynamics", IEEE/ACM
Transactions on Networking, 7(3), pages 277-292, June 1999.
[10] V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, "Framework for
IP Performance Metrics", RFC 2330, May 1998.
[11] K. Sriram and W. Whitt, "Characterizing superposition arrival [10] K. Sriram and W. Whitt, "Characterizing superposition arrival
processes in packet multiplexers for voice and data", IEEE processes in packet multiplexers for voice and data", IEEE
Journal on Selected Areas of Communication, pages 833-846, Journal on Selected Areas of Communication, pages 833-846,
September 1986, September 1986,
[12] M. Yajnik, J. Kurose and D. Towsley, "Packet loss correlation [11] M. Yajnik, J. Kurose and D. Towsley, "Packet loss correlation in
in the MBONE multicast network", Proceedings of IEEE Global the MBONE multicast network", Proceedings of IEEE Global
Internet, London, UK, November 1996. Internet, London, UK, November 1996.
Addresses Authors' Addresses
Questions about this memo can be directed to the authors: Rajeev Koodli
Communications Systems Lab
Nokia Research Center
313 Fairchild Drive
Mountain View, CA 94043
USA
Rajeev Koodli Rayadurgam Ravikanth Phone: +1-650 625-2359
Communications Systems Lab Axiowave Networks Inc. Fax: +1 650 625-2502
Nokia Research Center 100 Nickerson Road EMail: rajeev.koodli@nokia.com
313 Fairchild Drive Marlborough, MA- 01752
Mountain View, California 94043 USA Rayadurgam Ravikanth
USA Email: rravikanth@axiowave.com Axiowave Networks Inc.
Phone: +1-650 625-2359 200 Nickerson Road
EMail: rajeev.koodli@nokia.com Marlborough, MA 01752
Fax: +1 650 625-2502 USA
EMail: rravikanth@axiowave.com
Full Copyright Statement
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 139 change blocks. 
371 lines changed or deleted 360 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/