draft-ietf-ippm-loss-pattern-05.txt | draft-ietf-ippm-loss-pattern-06.txt | |||
---|---|---|---|---|

IP Performance Metrics (IPPM) WG Rajeev Koodli | IPPM Working Group Rajeev Koodli | |||

INTERNET DRAFT Nokia Research Center | INTERNET DRAFT Nokia Research Center | |||

20 July 2001 R. Ravikanth | 5 December 2001 R. Ravikanth | |||

Axiowave | Axiowave | |||

One-way Loss Pattern Sample Metrics | One-way Loss Pattern Sample Metrics | |||

<draft-ietf-ippm-loss-pattern-05.txt> | draft-ietf-ippm-loss-pattern-06.txt | |||

STATUS OF THIS MEMO | Status of This Memo | |||

This document is an Internet-Draft and is in full conformance with all | This document is an Internet-Draft and is in full conformance with | |||

provisions of Section 10 of RFC2026. | all provisions of Section 10 of RFC2026. | |||

Internet-Drafts are working documents of the Internet Engineering Task | Internet-Drafts are working documents of the Internet Engineering | |||

Force (IETF), its areas, and its working groups. Note that other groups | Task Force (IETF), its areas, and its working groups. Note that | |||

may also distribute working documents as Internet- Drafts. | other groups may also distribute working documents as Internet- | |||

Drafts. | ||||

Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six | |||

and may be updated, replaced, or obsoleted by other documents at any | months and may be updated, replaced, or obsoleted by other documents | |||

time. It is inappropriate to use Internet-Drafts as reference material | at any time. It is inappropriate to use Internet-Drafts as | |||

or to cite them other than as "work in progress." | reference material or to cite them other than as "work in progress." | |||

The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at: | |||

http://www.ietf.org/ietf/1id-abstracts.txt | http://www.ietf.org/ietf/1id-abstracts.txt | |||

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 memo | This memo provides information for the Internet community. This memo | |||

does not specify an Internet standard of any kind. Distribution of | does not specify an Internet standard of any kind. Distribution of | |||

this memo is unlimited. | this memo is unlimited. | |||

Abstract | Abstract | |||

The Internet exhibits certain specific types of behavior (e.g., bursty | The Internet exhibits certain specific types of behavior (e.g., | |||

packet loss) that can affect the performance seen by the users as | bursty packet loss) that can affect the performance seen by the users | |||

well as the operators. Currently, the focus has been on specifying | as well as the operators. Previously, the focus of the IPPM had | |||

base metrics such as delay, loss and connectivity under the | been on specifying base metrics such as delay, loss and connectivity | |||

framework described in [frame-work]. It is useful to capture | under the framework described in [10]. However, specific Internet | |||

specific Internet behaviors under the umbrella of IPPM framework, | behaviors can also be captured under the umbrella of IPPM framework, | |||

specifying new concepts while reusing existing guidelines as much as | specifying new concepts while reusing existing guidelines as much as | |||

possible. This draft proposes the use of "derived metrics" to | possible. This document defines metrics derived from the previously | |||

accomplish this, specifically providing means for capturing the loss | specified base metrics to capture loss patterns experienced by | |||

pattern on the Internet. | streams of packets on the Internet. | |||

Contents | ||||

Status of This Memo i | ||||

Abstract i | ||||

1. Introduction 2 | ||||

2. Terminology 2 | ||||

3. The Approach 2 | ||||

4. Basic Definitions 3 | ||||

5. Definitions for Samples of One-way Loss Distance, and One-way | ||||

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 | ||||

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 | ||||

8. IANA Considerations 11 | ||||

9. Acknowledgements 11 | ||||

Addresses 13 | ||||

1. Introduction | 1. Introduction | |||

In certain real-time applications (such as packet voice and video), | ||||

the loss pattern or loss distribution is a key parameter | In certain real-time applications (such as packet voice and | |||

that determines the performance observed by the users. For the same | video), the loss pattern or loss distribution is a key parameter | |||

loss rate, two different loss distributions could potentially produce | that determines the performance observed by the users. For the | |||

widely different perceptions of performance. The impact of loss pattern | same loss rate, two different loss distributions could potentially | |||

is also extremely important for non-real-time applications that use | produce widely different perceptions of performance. The impact | |||

an adaptive protocol such as TCP. There is ample evidence in the | of loss pattern is also extremely important for non-real-time | |||

literature indicating the importance and existence of loss burstiness | applications that use an adaptive protocol such as TCP. Refer | |||

and its effect on packet voice and video applications | to [2], [3], [5], [12] for evidence as to the importance and | |||

[Bolot], [Borella], [Handley], [Yajnik]. | existence of loss burstiness and its effect on packet voice and video | |||

applications. | ||||

In this document, we propose two derived metrics, called "loss distance" | In this document, we propose two derived metrics, called "loss | |||

and "loss period", with associated statistics, to capture packet loss | distance" and "loss period", with associated statistics, to capture | |||

patterns. The loss period metric captures the frequency and length | packet loss patterns. The loss period metric captures the frequency | |||

(burstiness) of loss once it starts, and the loss distance metric | and length (burstiness) of loss once it starts, and the loss | |||

captures the spacing between the loss periods. It is important to note | distance metric captures the spacing between the loss periods. It is | |||

that these metrics are derived based on the base metric | important to note that these metrics are derived based on the base | |||

Type-P-One-Way-packet-Loss. | metric Type-P-One-Way-packet-Loss. | |||

2. The Approach | 2. Terminology | |||

This document closely follows the guidelines specified in [frame-work]. | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL | |||

Specifically, the concepts of "singleton, sample, statistic", | NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and | |||

"silently ignore" in this document are to be interpreted as described | ||||

in RFC 2119 [4]. | ||||

3. The Approach | ||||

This document closely follows the guidelines specified in [10]. | ||||

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 draft 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 [AKZ], where it is noted | MAY be needed. Indeed, this is mentioned in [1], where it is | |||

that alternate sampling procedures may be useful depending on specific | noted that alternate sampling procedures may be useful depending | |||

circumstances. This draft proposes that the specific behaviors be | on specific circumstances. This draft proposes that the specific | |||

captured as "derived" metrics from the base metrics the behaviors | behaviors be captured as "derived" metrics from the base metrics the | |||

are related to. The reasons for adopting this position are the | behaviors are related to. The reasons for adopting this position are | |||

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 | different behaviors (e.g., a single definition of packet loss is | |||

is needed for capturing burst of losses, 'm out of n' losses | needed for capturing burst of losses, 'm out of n' losses etc.) | |||

etc. Otherwise, the metrics would have to be fundamentally | ||||

different) | ||||

- 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 behaviors | ||||

Following the guidelines in [frame-work], this | - it clearly separates few base metrics from many Internet | |||

translates to deriving sample metrics from the respective | behaviors | |||

singletons. The process of deriving sample metrics from the singletons | ||||

is specified in [frame-work], [AKZ], and others. | Following the guidelines in [10], this translates to deriving | |||

sample metrics from the respective singletons. The process | ||||

of deriving sample metrics from the singletons is specified | ||||

in [10], [1], and 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. | |||

3. Basic Definitions: | 4. Basic Definitions | |||

3.1. Bursty loss: | ||||

The loss involving consecutive packets of a stream. | ||||

3.2. Loss Distance: | ||||

The difference in sequence numbers of two successively lost | Sequence number: Consecutive packets in a time series sample | |||

packets which may or may not be separated by successfully | are given sequence numbers that are consecutive | |||

received packets. | integers. This document does not specify exactly | |||

how to associate sequence numbers with packets. The | ||||

sequence numbers could be contained within test | ||||

packets themselves, or they could be derived through | ||||

post-processing of the sample. | ||||

Example. Let packet with sequence number 50 be considered lost | Bursty loss: The loss involving consecutive packets of a stream. | |||

immediately after packet with sequence number 20 was | ||||

considered lost. The loss distance is 30. | ||||

Note that this definition does not specify exactly how to | Loss Distance: The difference in sequence numbers of two | |||

associate sequence numbers with test packets. In other words, from | successively lost packets which may or may not be | |||

a timeseries sample of test packets, one may derive the sequence | separated by successfully received packets. | |||

numbers. However, these sequence numbers must be consecutive | ||||

integers. | ||||

3.3. Loss period: | Example: In a packet stream, the packet with sequence number 20 | |||

is considered lost, followed by the packet with | ||||

sequence number 50. The loss distance is 30. | ||||

Let P_i be the i'th packet. | Loss period: Let P_i be the i'th packet. Define f(P_i) = 1 if P_i | |||

Define f(P_i) = 1 if P_i is lost, 0 otherwise. | is lost, 0 otherwise. Then, a loss period begins if | |||

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 received (denoted by r) packets. | and 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) is, | |||

f(P_i): 0 0 0 1 0 0 1 1 1 0 1 0 0 1 1 1 | f(P_i): 0 0 0 1 0 0 1 1 1 0 1 0 0 1 1 1 | |||

and there are four loss periods in the above sequence | and there are four loss periods in the above sequence | |||

beginning at P_3, P_6, P_10, and P_13. | beginning at P_3, P_6, P_10, and P_13. | |||

4. Definitions for Samples of One-way Loss Distance, | 5. Definitions for Samples of One-way Loss Distance, and One-way | |||

and One-way Loss Period. | Loss Period | |||

4.1 Metric Name: | 5.1. Metric Names | |||

4.1.1 Type-P-One-Way-Loss-Distance-Stream | 5.1.1. Type-P-One-Way-Loss-Distance-Stream | |||

4.1.2 Type-P-One-Way-Loss-Period-Stream | ||||

4.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 | ||||

+ T0, a time | ||||

+ Tf, a time | ||||

+ lambda, a rate in reciprocal of seconds | ||||

+ Path, the path from Src to Dst (See [AKZ] for comments) | ||||

4.3 Metric Units | Src, the IP address of a host | |||

4.3.1 Type-P-One-Way-Loss-Distance-Stream: | Dst, the IP address of a host | |||

A sequence of pairs of the form <loss distance, loss>, where loss | T0, a time | |||

is derived from the sequence of <time, loss> in [AKZ], and loss | ||||

Tf, a time | ||||

lambda, a rate of any sampling method chosen in reciprocal of | ||||

seconds | ||||

5.3. Metric Units | ||||

5.3.1. Type-P-One-Way-Loss-Distance-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. | distance is either zero or a positive integer. | |||

4.3.2 Type-P-One-Way-Loss-Period-Stream | 5.3.2. Type-P-One-Way-Loss-Period-Stream | |||

A sequence of pairs of the form <loss period, loss>, where loss is | A sequence of pairs of the form <loss period, loss>, where loss is | |||

derived from the sequence of <time, loss> in [AKZ], and loss period | derived from the sequence of <time, loss> in [1], and loss period is | |||

an integer. | an integer. | |||

4.4. Definitions: | 5.4. Definitions | |||

4.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 [AKZ]), we | When a packet is considered lost (using the definition in [1]), | |||

look at its sequence number and compare it with that of the | we 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 timeseries | The sequence number of a test packet can be derived from the | |||

sample collected by performing the loss measurement according to the | timeseries sample collected by performing the loss measurement | |||

methodology in [AKZ]. For example, if a loss sample consists of | according to the methodology in [1]. For example, if a loss sample | |||

{<T0,0>, <T1,0>, <T2,1>, <T3,0>, <T4,0>}, the sequence numbers of the | consists of <T0,0>, <T1,0>, <T2,1>, <T3,0>, <T4,0>, the sequence | |||

five test packets sent at T0, T1, T2, T3, and T4 can be 0, 1, 2, 3 and | numbers of the five test packets sent at T0, T1, T2, T3, and T4 can | |||

4 respectively, or 100, 101, 102, 103 and 104 respectively, etc. | be 0, 1, 2, 3 and 4 respectively, or 100, 101, 102, 103 and 104 | |||

respectively, etc. | ||||

4.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 counter is | We start a counter 'n' at an initial value of zero. This | |||

incremented by one each time a lost packet satisfies the Definition 3.3. | counter is incremented by one each time a lost packet satisfies the | |||

The metric is defined as <loss period, loss> where | definition outlined in 4. The metric is defined as <loss period, | |||

"loss" is derived from the sequence of <time, loss> in | loss> where "loss" is derived from the sequence of <time, loss> in | |||

Type-P-One-Way-Loss-Stream [AKZ], and | Type-P-One-Way-Loss-Stream [1], and loss period is set to zero when | |||

loss period is set to zero when "loss" is zero in | "loss" is zero in Type-P-One-Way-Loss-Stream, and loss period is set | |||

Type-P-One-Way-Loss-Stream, and loss period is set to 'n' (above) | to 'n' (above) when "loss" is one in Type-P-One-Way-Loss-Stream. | |||

when "loss" is one in Type-P-One-Way-Loss-Stream. | ||||

Essentially, when a packet is lost, the current value of "n" indicates | Essentially, when a packet is lost, the current value of "n" | |||

the loss period to which this packet belongs. For a packet that is | indicates the loss period to which this packet belongs. For a packet | |||

received successfully, the loss period is defined to be zero. | that is received successfully, the loss period is defined to be zero. | |||

4.4.3 Example: | 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>, | {<T1,0>,<T2,1>,<T3,0>,<T4,0>,<T5,1>,<T6,0>,<T7,1>,<T8,0>,<T9,1>,<T10,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 metrics | Packets sent at T2, T5, T7, T9, T10 are lost. The two derived | |||

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 distance | Since packet 2 is the first lost packet, the associated loss | |||

is zero. For the next lost packet (packet 5), loss distance is 5-2 or 3. | distance is zero. For the next lost packet (packet 5), loss distance | |||

Similarly, for the remaining lost packets (packets 7, 9, and 10) their | is 5-2 or 3. Similarly, for the remaining lost packets (packets | |||

loss distances are 2, 2, and 1 respectively. Therefore, the | 7, 9, and 10) their loss distances are 2, 2, and 1 respectively. | |||

Type-P-One-Way-Loss-Distance-Stream is: | Therefore, 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 by one | The packet 2 sets the counter 'n' to 1, which is incremented | |||

for packets 5, 7 and 9 according to Definition 3.3. However, for | by one for packets 5, 7 and 9 according to the definition in 4. | |||

packet 10, the counter remains at 4 satisfying Definition 3.3 again. | However, for packet 10, the counter remains at 4, again satisfying | |||

Thus, the Type-P-One-Way-Loss-Period-Stream is: | the 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>} | |||

4.5. Methodologies: | 5.5. Methodologies | |||

The same methodology outlined in [AKZ] can be used to conduct the | The same methodology outlined in [1] can be used to conduct the | |||

sample experiments. | sample experiments. A synopsis is listed below. | |||

4.6 Discussion: | Generally, for a given Type-P, one possible methodology would | |||

proceed as follows: | ||||

- Arrange that Src and Dst have clocks that are synchronized with | ||||

each other. The degree of synchronization is a parameter of the | ||||

methodology, and depends on the threshold used to determine loss | ||||

(see below). | ||||

- At the Src host, select Src and Dst IP addresses, and form a test | ||||

packet of Type-P with these addresses. | ||||

- At the Dst host, arrange to receive the packet. | ||||

- At the Src host, place a timestamp in the prepared Type-P packet, | ||||

and send it towards Dst. | ||||

- If the packet arrives within a reasonable period of time, the | ||||

one-way packet-loss is taken to be zero. | ||||

- If the packet fails to arrive within a reasonable period of | ||||

time, the one-way packet-loss is taken to be one. Note that the | ||||

threshold of "reasonable" here is a parameter of the methodology. | ||||

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 | between packet losses. This could be useful in determining a "spread | |||

"spread factor" associated with the packet loss rate. For | factor" associated with the packet loss rate. In conjunction, the | |||

example, for a given packet loss rate, this metric | Loss-Period-Stream metric allows the study of loss burstiness for | |||

indicates how the losses are spread. On the other hand, | each occurrence of loss. A single loss period of length 'n' can | |||

the Loss-Period-Stream metric allows the study of loss burstiness | account for a significant portion of the overall loss rate. Note | |||

for each occurrence of loss. Note that a single loss period of | that it is possible to measure distance between loss bursts separated | |||

length 'n' can account for a significant portion of the overall | by one or more successfully received packets. (Refer to Sections 6.4 | |||

loss rate. Note also that it is possible to measure distance between | and 6.5). | |||

loss bursts seprated by one or more successfully received packets: See | ||||

Section 5.4, and 5.5 | ||||

4.7 Sampling Considerations: | 5.7. Sampling Considerations | |||

The proposed metrics can be used independent of the | The proposed metrics can be used independent of the particular | |||

particular sampling method used. We note that Poisson sampling | sampling method used. We note that Poisson sampling may not | |||

may not yield appropriate values for these metrics for | yield appropriate values for these metrics for certain real-time | |||

certain real-time applications such as voice over IP, as well as to | applications such as voice over IP, as well as to TCP-based | |||

TCP-based applications. For real-time applications, it may be more | applications. For real-time applications, it may be more appropriate | |||

appropriate to use the ON-OFF [Sriram] model, in which an ON period | to use the ON-OFF [11] model, in which an ON period starts with | |||

starts with certain probability 'p', during which certain number of | certain probability 'p', during which certain number of packets | |||

packets are transmitted with mean 'lambda-on' according to geometric | are transmitted with mean 'lambda-on' according to geometric | |||

distribution and an OFF period starts with probability '1-p' and | distribution and an OFF period starts with probability '1-p' and | |||

lasts for a period of time based on exponential distribution with | lasts for a period of time based on exponential distribution with | |||

rate 'lambda-off'. | rate 'lambda-off'. | |||

For TCP-based applications, one may use the model proposed in | For TCP-based applications, one may use the model proposed in [7]. | |||

[Padhye1]. See [Padhye2] for an application of the model. | See [8] for an application of the model. | |||

5. Statistics: | 5.8. Errors and Uncertainties | |||

5.1 Type-P-One-Way-Loss-Noticeable-Rate | The measurement aspects, including the packet size, loss | |||

threshold, type of the test machine chosen etc, invariably influence | ||||

the packet loss metric itself and hence the derived metrics described | ||||

in this document. Thus, when making assessment of the results | ||||

pertaining to the metrics outlined in this document, attention must | ||||

be paid to these matters. See [1] for a detailed consideration of | ||||

errors and uncertainties regarding the measurement of base packet | ||||

loss metric. | ||||

Define loss of a packet to be "noticeable" [RK97] if the distance | 6. Statistics | |||

between the lost packet and the previously lost packet is no | ||||

greater than delta, a positive integer, where delta is the | ||||

"loss constraint". | ||||

Example. Let delta = 99. Let us assume that packet 50 is lost | 6.1. Type-P-One-Way-Loss-Noticeable-Rate | |||

followed by a bursty loss of length 3 starting from | ||||

packet 125. | ||||

All the *four* losses are noticeable. | ||||

Given a Type-P-One-Way-Loss-Distance-Stream, this statistic | Define loss of a packet to be "noticeable" [6] if the distance | |||

can be computed simply as the number of losses that violate some | between the lost packet and the previously lost packet is no greater | |||

constraint delta, divided by the number of losses. (Alternately, it | than delta, a positive integer, where delta is the "loss constraint". | |||

can also be defined as the number of "noticeable losses" to the number | ||||

of successfully received packets). This statistic is useful when the | 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 | ||||

the three losses starting from packet 125 are noticeable. | ||||

Given a Type-P-One-Way-Loss-Distance-Stream, this statistic can be | ||||

computed simply as the number of losses that violate some constraint | ||||

delta, divided by the number of losses. (Alternatively, it can also | ||||

be defined as the number of "noticeable losses" to the number of | ||||

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 chosing delta based on this sensitivity, one can | close distances. By choosing delta based on this sensitivity, one | |||

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 the timeseries. In the above example where loss constraint is equal | in the timeseries. In the above example where loss constraint is | |||

to 99, a loss rate of one percent with a spread of 100 between | equal to 99, a loss rate of one percent with a spread of 100 between | |||

losses (e.g., 100, 200, 300, 400, 500 out of 500 packets) may be more | losses (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 | spread that violates the loss constraint (e.g., 100, 175, 275, 290, | |||

(e.g., 100, 175, 275, 290, 400: losses occuring at 175 and 290 | 400: losses occurring at 175 and 290 violate delta = 99). | |||

violate delta = 99). | ||||

5.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 derived | This represents the total number of loss periods, and can be | |||

from the loss period metric Type-P-One-Way-Loss-Period-Stream as | derived from the loss period metric Type-P-One-Way-Loss-Period-Stream | |||

follows: | as follows: | |||

Type-P-One-Way-Loss-Period-Total = maximum value of the first entry | Type-P-One-Way-Loss-Period-Total = maximum value of the first | |||

of the set of pairs, <loss period, loss>, representing the loss metric | entry of the set of pairs, <loss period, loss>, representing the loss | |||

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 loss | Note that this statistic does not describe the duration of each | |||

period itself. If this statistic is large, it does not mean that the | loss period itself. If this statistic is large, it does not mean | |||

losses are more spread out than they are otherwise; one or more | that the losses are more spread out than they are otherwise; one | |||

loss periods may include bursty losses. This statistic is generally | or more loss periods may include bursty losses. This statistic is | |||

useful in gathering first order of approximation of loss spread. | generally useful in gathering first order of approximation of loss | |||

spread. | ||||

5.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, length>, with the | This statistic is a sequence of pairs <loss period, | |||

"loss period" entry ranging from 1 - Type-P-One-Way-Loss-Period-Total. | length>, with the "loss period" entry ranging from 1 - | |||

Thus the total number of pairs in this statistic equals | Type-P-One-Way-Loss-Period-Total. Thus the total number of | |||

Type-P-One-Way-Loss-Period-Total. In each pair, the "length" is | pairs in this statistic equals Type-P-One-Way-Loss-Period-Total. In | |||

obtained by counting the number of pairs, <loss period, loss>, in the | each pair, the "length" is obtained by counting the number of pairs, | |||

metric Type-P-One-Way-Loss-Period-Stream which have first entry equal | <loss period, loss>, in the metric Type-P-One-Way-Loss-Period-Stream | |||

to "loss period." | which have first entry 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. In | loss period, it is an indicator of burstiness of each loss period. | |||

conjunction with loss-period-total statistic, this statistic is generally | In conjunction with loss-period-total statistic, this statistic is | |||

useful in observing which loss periods are potentially more influential | generally useful in observing which loss periods are potentially more | |||

than others from a quality perspective. | influential than others from a quality perspective. | |||

5.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 periods. It | This statistic measures distance between successive loss | |||

takes the form of a set of pairs | periods. It takes the form of a set of pairs <loss period, | |||

<loss period, inter-loss-period-length>, with the | inter-loss-period-length>, with the "loss period" entry ranging from | |||

"loss period" entry ranging from 1 - Type-P-One-Way-Loss-Period-Total, | 1 - Type-P-One-Way-Loss-Period-Total, and "inter-loss-period-length" | |||

and "inter-loss-period-length" is the loss distance between the last | is the loss distance between the last packet considered lost in "loss | |||

packet considered lost in "loss period" 'i-1', and the first packet | period" 'i-1', and the first packet considered lost in "loss period" | |||

considered lost in "loss period" 'i', where 'i' ranges from 2 to | 'i', where 'i' ranges from 2 to Type-P-One-Way-Loss-Period-Total. | |||

Type-P-One-Way-Loss-Period-Total. The "inter-loss-period-length" | The "inter-loss-period-length" associated with the first "loss | |||

associated with the first "loss period" is defined to be zero. | period" is defined to be zero. | |||

This statistic allows one to consider, for example, two loss periods each | This statistic allows one to consider, for example, two loss | |||

of length greater than one (implying loss burst), but separated by a | periods each of length greater than one (implying loss burst), but | |||

distance of 2 to belong to the same loss burst if such a consideration | separated by a distance of 2 to belong to the same loss burst if such | |||

is deemed useful. When the Inter-Loss-Period-Length between two bursty | a consideration is deemed useful. When the Inter-Loss-Period-Length | |||

loss periods is smaller, it could affect the loss concealing ability of | between two bursty loss periods is smaller, it could affect the loss | |||

multimedia codecs since there is relatively smaller history. When it is | concealing ability of multimedia codecs since there is relatively | |||

larger, an application may be able to rebuild its history which could | smaller history. When it is larger, an application may be able to | |||

dampen the effect of an impending loss (period). | rebuild its history which could dampen the effect of an impending | |||

loss (period). | ||||

5.5 Example | 6.5. Examples | |||

We continue with the same example as in Section 4.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. | - Let delta = 2. In Type-P-One-Way-Loss-Distance-Stream | |||

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>}, there | ||||

are 3 loss distances that violate the delta of 2. Thus, | ||||

Type-P-One-Way-Loss-Noticeable-Rate = 3/5 | {<0,0>,<0,1>,<0,0>,<0,0>,<3,1>,<0,0>,<2,1>,<0,0>,<2,1>,<1,1>}, | |||

((number of noticeable losses)/(number of total losses)) | there are 3 loss distances that violate the delta of 2. Thus, | |||

+ In Type-P-One-Way-Loss-Period-Stream | Type-P-One-Way-Loss-Noticeable-Rate = 3/5 ((number of noticeable | |||

{<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, the | losses)/(number of total losses)) | |||

largest of the first entry in the sequence of <loss period,loss> | ||||

pairs is 4. Thus, | - 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>}, | ||||

the largest of the first entry in the sequence of <loss | ||||

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>}, the | ||||

lengths of individual loss periods are 1, 1, 1 and 2 respectively. | ||||

Thus, | ||||

Type-P-One-Way-Loss-Period-Lengths = {<1,1>,<2,1>,<3,1>,<4,2>} | {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, | |||

+ In Type-P-One-Way-Loss-Period-Stream | the lengths of individual loss periods are 1, 1, 1 and 2 | |||

{<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, the | respectively. Thus, | |||

loss periods 1 and 2 are separated by 3 (5-2), loss periods 2 and 3 | ||||

are separated by 2 (7-5), and 3 and 4 are separated by 2 (9-7). | ||||

Thus, | ||||

Type-P-One-Way-Inter-Loss-Period-Lengths = {<1,0>,<2,3>,<3,2>,<4,2>} | ||||

6. Security Considerations | Type-P-One-Way-Loss-Period-Lengths = | |||

Since this draft proposes sample metrics based on the base loss metric | {<1,1>,<2,1>,<3,1>,<4,2>} | |||

defined in [AKZ], it inherits the security considerations mentioned in | ||||

[AKZ]. | ||||

7. Acknowledgements | - In Type-P-One-Way-Loss-Period-Stream | |||

Many thanks to Matt Zekauskas for the constructive feedback on the draft. | {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>}, | |||

Thanks to Guy Almes for encouraging the work, and Vern Paxson for the | ||||

comments during the IETF meetings. Thanks to Steve Glass for making the | ||||

presentation at the Oslo meeting. | ||||

8. References | the loss periods 1 and 2 are separated by 3 (5-2), loss periods | |||

2 and 3 are separated by 2 (7-5), and 3 and 4 are separated by 2 | ||||

(9-7). Thus, | ||||

Type-P-One-Way-Inter-Loss-Period-Lengths = | ||||

[AKZ] G. Almes and S. Kalindindi and M. Zekauskas, "A One-way Packet | {<1,0>,<2,3>,<3,2>,<4,2>} | |||

Loss Metric for IPPM", RFC 2680, September 1999 | ||||

[Bolot] J.-C. Bolot and A. vega Garcia, "The case for FEC-based | 7. Security Considerations: | |||

error control for Packet Audio in the Internet", ACM Multimedia | ||||

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 | ||||

concerns. This document does not specify a particular implementation | ||||

of metrics, so it does not directly affect the security of the | ||||

Internet nor of applications which run on the Internet. However, | ||||

implementations of these metrics must be mindful of security and | ||||

privacy concerns. | ||||

The derived sample metrics in this document are based on the loss | ||||

metric defined in RFC-2680 [1], and thus they inherit the security | ||||

considerations of that document. The reader should consult [1] for a | ||||

more detailed treatment of security considerations. | ||||

Nevertheless, there are a few things to highlight. First, | ||||

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 | ||||

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. Third, the results could be perturbed by attempting to corrupt | ||||

or disrupt the underlying stream, for example adding extra packets | ||||

that look just like test packets. | ||||

In general, legitimate measurements must have their parameters | ||||

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 | ||||

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. | ||||

9. Acknowledgements | ||||

Matt Zekauskas provided insightful feedback and the text for the | ||||

Security Considerations section. We sincerely thank him for his | ||||

painstaking review and for supporting this work along with Merike | ||||

Kaeo. Thanks to Guy Almes for encouraging the work, and Vern Paxson | ||||

for the comments during the IETF meetings. Thanks to Steve Glass for | ||||

making the presentation at the Oslo meeting. | ||||

References | ||||

[1] G. Almes and S. Kalindindi and M. Zekauskas, "A One-way Packet | ||||

Loss Metric for IPPM", RFC 2680, September 1999. | ||||

[2] J.-C. Bolot and A. vega Garcia, "The case for FEC-based error | ||||

control for Packet Audio in the Internet", ACM Multimedia | ||||

Systems, 1997. | Systems, 1997. | |||

[Borella] M. S. Borella, D. Swider, S. Uludag, and G. B. Brewster, | [3] M. S. Borella, D. Swider, S. Uludag, and G. B. Brewster, | |||

"Internet Packet Loss: Measurement and Implications for End-to-End | "Internet Packet Loss: Measurement and Implications for | |||

QoS," Proceedings, International Conference on Parallel Processing, | End-to-End QoS," Proceedings, International Conference on | |||

August 1998. | Parallel Processing, August 1998. | |||

[Handley] M. Handley, "An examination of MBONE performance", | [4] S. Bradner, "Key words for use in RFCs to Indicate Requirement | |||

Technical Report, USC/ISI, ISI/RR-97-450, July 1997 | Levels," RFC 2119, Internet Engineering Task Force, March 1997. | |||

[RK97] R. Koodli, "Scheduling Support for Multi-tier Quality of | [5] M. Handley, "An examination of MBONE performance", Technical | |||

Report, USC/ISI, ISI/RR-97-450, July 1997 | ||||

[6] R. Koodli, "Scheduling Support for Multi-tier Quality of | ||||

Service in Continuous Media Applications", PhD dissertation, | Service in Continuous Media Applications", PhD dissertation, | |||

Electrical and Computer Engineering Department, University of | Electrical and Computer Engineering Department, University of | |||

Massachusetts, Amherst, MA 01003. | Massachusetts, Amherst, MA 01003, September 1997. | |||

[Padhye1] J. Padhye, V. Firoiu, J. Kurose and D. Towsley, "Modeling | [7] J. Padhye, V. Firoiu, J. Kurose and D. Towsley, "Modeling TCP | |||

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. | |||

[Padhye2] J. Padhye, J. Kurose, D. Towsley and R. Koodli, "A | [8] J. Padhye, J. Kurose, D. Towsley and R. Koodli, "A TCP-friendly | |||

TCP-friendly rate adjustment protocol for continuous media flows | rate adjustment protocol for continuous media flows over | |||

over best-effort networks", short paper presentation in | best-effort networks", short paper presentation in ACM | |||

ACM SIGMETRICS'99. Available as Umass Computer Science tech report | SIGMETRICS'99. Available as Umass Computer Science tech report | |||

from ftp://gaia.cs.umass.edu/pub/Padhye98-tcp-friendly-TR.ps.gz | from ftp://gaia.cs.umass.edu/pub/Padhye98-tcp-friendly-TR.ps.gz | |||

[Paxson] V. Paxson, "End-to-end Internet packet dynamics", Computer | [9] V. Paxson, "End-to-end Internet packet dynamics", IEEE/ACM | |||

Communication review, Proceedings of ACM SIGCOMM'97 Conference, | Transactions on Networking, 7(3), pages 277-292, June 1999. | |||

Cannes, France, September 1997, 27(4), pages 139-152, October 1997 | ||||

[frame-work] V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, | [10] V. Paxson, G. Almes, J. Mahdavi, and M. Mathis, "Framework for | |||

"Framework for IP Performance Metrics", RFC 2330, May 1998. | IP Performance Metrics", RFC 2330, May 1998. | |||

[Sriram] K. Sriram and W. Whitt, "Characterizing superposition | [11] K. Sriram and W. Whitt, "Characterizing superposition arrival | |||

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, September 1986, pages | Journal on Selected Areas of Communication, pages 833-846, | |||

833-846 | September 1986, | |||

[Yajnik] M. Yajnik, J. Kurose and D. Towsley, "Packet loss | [12] M. Yajnik, J. Kurose and D. Towsley, "Packet loss correlation | |||

correlation in the MBONE multicast network", Proceedings of IEEE | in the MBONE multicast network", Proceedings of IEEE Global | |||

Global Internet, London, UK, November 1996. | Internet, London, UK, November 1996. | |||

Author's Addresses | Addresses | |||

Rajeev Koodli | Questions about this memo can be directed to the authors: | |||

Nokia Research Center | ||||

313, Fairchild Drive | ||||

Mountain View, CA 94043 | ||||

Phone: +1 650-625-2359 | ||||

Email: rajeev.koodli@nokia.com | ||||

Rayadurgam Ravikanth | Rajeev Koodli Rayadurgam Ravikanth | |||

Axiowave Networks Inc. | Communications Systems Lab Axiowave Networks Inc. | |||

100 Nickerson Road | Nokia Research Center 100 Nickerson Road | |||

Marlborough, MA- 01752 | 313 Fairchild Drive Marlborough, MA- 01752 | |||

Email: rravikanth@axiowave.com | Mountain View, California 94043 USA | |||

USA Email: rravikanth@axiowave.com | ||||

Phone: +1-650 625-2359 | ||||

EMail: rajeev.koodli@nokia.com | ||||

Fax: +1 650 625-2502 | ||||

End of changes. | ||||

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