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