RFC3357 日本語訳

3357 One-way Loss Pattern Sample Metrics. R. Koodli, R. Ravikanth. August 2002. (Format: TXT=30570 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                          R. Koodli
Request for Comments: 3357                         Nokia Research Center
Category: Informational                                     R. Ravikanth
                                                                Axiowave
                                                             August 2002

Network Working Group R. Koodli Request for Comments: 3357 Nokia Research Center Category: Informational R. Ravikanth Axiowave August 2002

                  One-way Loss Pattern Sample Metrics

One-way Loss Pattern Sample Metrics

Status of this Memo

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.

Copyright Notice

Copyright Notice

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright (C) The Internet Society (2002). All Rights Reserved.

Abstract

Abstract

   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.

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.

Koodli & Ravikanth           Informational                      [Page 1]

RFC 3357          One-way Loss Pattern Sample Metrics        August 2002

Koodli & Ravikanth Informational [Page 1] RFC 3357 One-way Loss Pattern Sample Metrics August 2002

Table of Contents

Table of Contents

   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

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

Koodli & Ravikanth           Informational                      [Page 2]

RFC 3357          One-way Loss Pattern Sample Metrics        August 2002

Koodli & Ravikanth Informational [Page 2] RFC 3357 One-way Loss Pattern Sample Metrics August 2002

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 that
   determines the performance observed by the users.  For the same loss
   rate, two different loss distributions could potentially produce
   widely different perceptions of performance.  The impact of loss
   pattern is also extremely important for non-real-time applications
   that use an adaptive protocol such as TCP.  Refer to [4], [5], [6],
   [11] for evidence as to the importance and existence of loss
   burstiness and its effect on packet voice and video applications.

In certain real-time applications (such as packet voice and video), the loss pattern or loss distribution is a key parameter that determines the performance observed by the users. For the same loss rate, two different loss distributions could potentially produce widely different perceptions of performance. The impact of loss pattern is also extremely important for non-real-time applications that use an adaptive protocol such as TCP. Refer to [4], [5], [6], [11] for evidence as to the importance and existence of loss burstiness and its effect on packet voice and video applications.

   Previously, the focus of the IPPM had been on specifying base metrics
   such as delay, loss and connectivity under the framework described in
   RFC 2330.  However, specific Internet behaviors can also be captured
   under the umbrella of the IPPM framework, specifying new concepts
   while reusing existing guidelines as much as possible.  In this
   document, we propose two derived metrics, called "loss distance" and
   "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.

Previously, the focus of the IPPM had been on specifying base metrics such as delay, loss and connectivity under the framework described in RFC 2330. However, specific Internet behaviors can also be captured under the umbrella of the IPPM framework, specifying new concepts while reusing existing guidelines as much as possible. In this document, we propose two derived metrics, called "loss distance" and "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 NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and
   "silently ignore" in this document are to be interpreted as described
   in BCP 14, RFC 2119 [2].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL", and "silently ignore" in this document are to be interpreted as described in BCP 14, RFC 2119 [2].

3. The Approach

3. The Approach

   This document closely follows the guidelines specified in [3].
   Specifically, the concepts of singleton, sample, statistic,
   measurement principles, Type-P packets, as well as standard-formed
   packets all apply.  However, since the document proposes to capture
   specific Internet behaviors, modifications to the sampling process
   MAY be needed.  Indeed, this is mentioned in [1], where it is noted
   that alternate sampling procedures may be useful depending on
   specific circumstances.  This document proposes that the specific
   behaviors be captured as "derived" metrics from the base metrics the
   behaviors are related to.  The reasons for adopting this position are
   the following:

This document closely follows the guidelines specified in [3]. Specifically, the concepts of singleton, sample, statistic, measurement principles, Type-P packets, as well as standard-formed packets all apply. However, since the document proposes to capture specific Internet behaviors, modifications to the sampling process MAY be needed. Indeed, this is mentioned in [1], where it is noted that alternate sampling procedures may be useful depending on specific circumstances. This document proposes that the specific behaviors be captured as "derived" metrics from the base metrics the behaviors are related to. The reasons for adopting this position are the following:

Koodli & Ravikanth           Informational                      [Page 3]

RFC 3357          One-way Loss Pattern Sample Metrics        August 2002

Koodli & Ravikanth Informational [Page 3] RFC 3357 One-way Loss Pattern Sample Metrics August 2002

   -  it provides consistent usage of singleton metric definition for
      different behaviors (e.g., a single definition of packet loss is
      needed for capturing burst of losses, 'm out of n' losses etc.)

- it provides consistent usage of singleton metric definition for different behaviors (e.g., a single definition of packet loss is needed for capturing burst of losses, 'm out of n' losses etc.)

   -  it allows re-use of the methodologies specified for the singleton
      metric with modifications whenever necessary

- it allows re-use of the methodologies specified for the singleton metric with modifications whenever necessary

   -  it clearly separates few base metrics from many Internet behaviors

- it clearly separates few base metrics from many Internet behaviors

   Following the guidelines in [3], this translates to deriving sample
   metrics from the respective singletons.  The process of deriving
   sample metrics from the singletons is specified in [3], [1], and
   others.

Following the guidelines in [3], this translates to deriving sample metrics from the respective singletons. The process of deriving sample metrics from the singletons is specified in [3], [1], and others.

   In the following sections, we apply this approach to a particular
   Internet behavior, namely the packet loss process.

In the following sections, we apply this approach to a particular Internet behavior, namely the packet loss process.

4. Basic Definitions

4. Basic Definitions

   Sequence number: Consecutive packets in a time series sample are
                    given sequence numbers that are consecutive
                    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.

Sequence number: Consecutive packets in a time series sample are given sequence numbers that are consecutive 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.

   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 successively
                  lost packets which may or may not be separated by
                  successfully received packets.

Loss Distance: The difference in sequence numbers of two successively lost packets which may or may not be separated by successfully received packets.

   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.

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.

   Loss period: Let P_i be the i'th packet.  Define f(P_i) = 1 if P_i is
                lost, 0 otherwise.  Then, a loss period begins if
                f(P_i) = 1 and f(P_(i-1)) = 0

Loss period: Let P_i be the i'th packet. Define f(P_i) = 1 if P_i is lost, 0 otherwise. Then, a loss period begins if f(P_i) = 1 and f(P_(i-1)) = 0

   Example: Consider the following sequence of lost (denoted by x) and
            received (denoted by r) packets.

Example: Consider the following sequence of lost (denoted by x) 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

Koodli & Ravikanth           Informational                      [Page 4]

RFC 3357          One-way Loss Pattern Sample Metrics        August 2002

Koodli & Ravikanth Informational [Page 4] RFC 3357 One-way Loss Pattern Sample Metrics August 2002

   Then, with `i' assigned as follows,
                               1 1 1 1 1 1
   i:      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

Then, with `i' assigned as follows, 1 1 1 1 1 1 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 beginning at
      P_3, P_6, P_10, and P_13.

and there are four loss periods in the above sequence beginning at P_3, P_6, P_10, and P_13.

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

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

5.1. Metric Names

5.1. Metric Names

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

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

5.1.2. Type-P-One-Way-Loss-Period-Stream

5.1.2. Type-P-One-Way-Loss-Period-Stream

5.2. Metric Parameters

5.2. Metric Parameters

   Src,         the IP address of a host

Src, the IP address of a host

   Dst,         the IP address of a host

Dst, the IP address of a host

   T0,          a time

T0, a time

   Tf,          a time

Tf, a time

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

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

5.3. Metric Units

5.3. Metric Units

5.3.1. Type-P-One-Way-Loss-Distance-Stream

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.

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.

5.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
   derived from the sequence of <time, loss> in [1], and loss period is
   an integer.

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

Koodli & Ravikanth           Informational                      [Page 5]

RFC 3357          One-way Loss Pattern Sample Metrics        August 2002

Koodli & Ravikanth Informational [Page 5] RFC 3357 One-way Loss Pattern Sample Metrics August 2002

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]), we
   look at its sequence number and compare it with that of the
   previously lost packet.  The difference is the loss distance between
   the lost packet and the previously lost packet.  The sample would
   consist of <loss distance, loss> pairs.  This definition assumes that
   sequence numbers of successive test packets increase monotonically by
   one.  The loss distance associated with the very first packet loss is
   considered to be zero.

When a packet is considered lost (using the definition in [1]), we look at its sequence number and compare it with that of the previously lost packet. The difference is the loss distance between the lost packet and the previously lost packet. The sample would consist of <loss distance, loss> pairs. This definition assumes that sequence numbers of successive test packets increase monotonically by one. The loss distance associated with the very first packet loss is considered to be zero.

   The sequence number of a test packet can be derived from the
   timeseries sample collected by performing the loss measurement
   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
   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
   respectively, etc.

The sequence number of a test packet can be derived from the timeseries sample collected by performing the loss measurement 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 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 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 counter is
   incremented by one each time a lost packet satisfies the definition
   outlined in 4.  The metric is defined as <loss period, loss> where
   "loss" is derived from the sequence of <time, loss> in Type-P-One-
   Way-Loss-Stream [1], and loss period is set to zero when "loss" is
   zero in Type-P-One-Way-Loss-Stream, and loss period is set to 'n'
   (above) when "loss" is one in Type-P-One-Way-Loss-Stream.

We start a counter 'n' at an initial value of zero. This counter is incremented by one each time a lost packet satisfies the definition outlined in 4. The metric is defined as <loss period, loss> where "loss" is derived from the sequence of <time, loss> in Type-P-One- Way-Loss-Stream [1], and loss period is set to zero when "loss" is zero in Type-P-One-Way-Loss-Stream, and loss period is set to 'n' (above) when "loss" is one in Type-P-One-Way-Loss-Stream.

   Essentially, when a packet is lost, the current value of "n"
   indicates the loss period to which this packet belongs.  For a packet
   that is received successfully, the loss period is defined to be zero.

Essentially, when a packet is lost, the current value of "n" indicates the loss period to which this packet belongs. For a packet 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.

Koodli & Ravikanth           Informational                      [Page 6]

RFC 3357          One-way Loss Pattern Sample Metrics        August 2002

Koodli & Ravikanth Informational [Page 6] RFC 3357 One-way Loss Pattern Sample Metrics August 2002

   Packets sent at T2, T5, T7, T9, T10 are lost.  The two derived
   metrics can be obtained from this sample as follows.

Packets sent at T2, T5, T7, T9, T10 are lost. The two derived 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
   is zero.  For the next lost packet (packet 5), loss distance is 5-2
   or 3.  Similarly, for the remaining lost packets (packets 7, 9, and
   10) their loss distances are 2, 2, and 1 respectively.  Therefore,
   the Type-P-One-Way-Loss-Distance-Stream is:

Since packet 2 is the first lost packet, the associated loss distance is zero. For the next lost packet (packet 5), loss distance is 5-2 or 3. Similarly, for the remaining lost packets (packets 7, 9, and 10) their loss distances are 2, 2, and 1 respectively. 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
   for packets 5, 7 and 9 according to the definition in 4.  However,
   for packet 10, the counter remains at 4, again satisfying the
   definition in 4.  Thus, the Type-P-One-Way-Loss-Period-Stream is:

The packet 2 sets the counter 'n' to 1, which is incremented by one for packets 5, 7 and 9 according to the definition in 4. However, for packet 10, the counter remains at 4, again satisfying 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>}

5.5. Methodologies

5.5. Methodologies

   The same methodology outlined in [1] can be used to conduct the
   sample experiments.  A synopsis is listed below.

The same methodology outlined in [1] can be used to conduct the sample experiments. A synopsis is listed below.

   Generally, for a given Type-P, one possible methodology would proceed
   as follows:

Generally, for a given Type-P, one possible methodology would proceed as follows:

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

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

- 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 arrives within a reasonable period of time, the one-way packet-loss is taken to be zero.

Koodli & Ravikanth           Informational                      [Page 7]

RFC 3357          One-way Loss Pattern Sample Metrics        August 2002

Koodli & Ravikanth Informational [Page 7] RFC 3357 One-way Loss Pattern Sample Metrics August 2002

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

- 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

5.6. Discussion

   The Loss-Distance-Stream metric allows one to study the separation
   between packet losses.  This could be useful in determining a "spread
   factor" associated with the packet loss rate.  In conjunction, the
   Loss-Period-Stream metric allows the study of loss burstiness for
   each occurrence of loss.  A single loss period of length 'n' can
   account for a significant portion of the overall loss rate.  Note
   that it is possible to measure distance between loss bursts separated
   by one or more successfully received packets.  (Refer to Sections 6.4
   and  6.5).

The Loss-Distance-Stream metric allows one to study the separation between packet losses. This could be useful in determining a "spread factor" associated with the packet loss rate. In conjunction, the Loss-Period-Stream metric allows the study of loss burstiness for each occurrence of loss. A single loss period of length 'n' can account for a significant portion of the overall loss rate. Note that it is possible to measure distance between loss bursts separated by one or more successfully received packets. (Refer to Sections 6.4 and 6.5).

5.7. Sampling Considerations

5.7. Sampling Considerations

   The proposed metrics can be used independent of the particular
   sampling method used.  We note that Poisson sampling may not yield
   appropriate values for these metrics for certain real-time
   applications such as voice over IP, as well as to TCP-based
   applications.  For real-time applications, it may be more appropriate
   to use the ON-OFF [10] model, in which an ON period starts with a
   certain probability 'p', during which a certain number of packets are
   transmitted with mean 'lambda-on' according to geometric distribution
   and an OFF period starts with probability '1-p' and lasts for a
   period of time based on exponential distribution with rate 'lambda-
   off'.

The proposed metrics can be used independent of the particular sampling method used. We note that Poisson sampling may not yield appropriate values for these metrics for certain real-time applications such as voice over IP, as well as to TCP-based applications. For real-time applications, it may be more appropriate to use the ON-OFF [10] model, in which an ON period starts with a certain probability 'p', during which a certain number of packets are transmitted with mean 'lambda-on' according to geometric distribution and an OFF period starts with probability '1-p' and lasts for a period of time based on exponential distribution with rate 'lambda- off'.

   For TCP-based applications, one may use the model proposed in [8].
   See [9] for an application of the model.

For TCP-based applications, one may use the model proposed in [8]. 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 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 an 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.

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

Koodli & Ravikanth           Informational                      [Page 8]

RFC 3357          One-way Loss Pattern Sample Metrics        August 2002

Koodli & Ravikanth Informational [Page 8] RFC 3357 One-way Loss Pattern Sample Metrics August 2002

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" [7] if the distance
   between the lost packet and the previously lost packet is no greater
   than delta, a positive integer, where delta is the "loss constraint".

Define loss of a packet to be "noticeable" [7] if the distance 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
   followed by a bursty loss of length 3 starting from packet 125.  All
   the three losses starting from packet 125 are noticeable.

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,
   many multimedia codecs can sustain losses by "concealing" the effect
   of loss by making use of past history information.  Their ability to
   do so degrades with poor history resulting from losses separated by
   close distances.  By choosing delta based on this sensitivity, one
   can measure how "noticeable" a loss might be for quality purposes.
   The noticeable loss requires a certain "spread factor" for losses in
   the timeseries.  In the above example where loss constraint is 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
   desirable for some applications compared to the same loss rate with a
   spread that violates the loss constraint (e.g., 100, 175, 275, 290,
   400:  losses occurring at 175 and 290 violate delta = 99).

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, many multimedia codecs can sustain losses by "concealing" the effect of loss by making use of past history information. Their ability to do so degrades with poor history resulting from losses separated by close distances. By choosing delta based on this sensitivity, one can measure how "noticeable" a loss might be for quality purposes. The noticeable loss requires a certain "spread factor" for losses in the timeseries. In the above example where loss constraint is 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 desirable for some applications compared to the same loss rate with a spread that violates the loss constraint (e.g., 100, 175, 275, 290, 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 derived
   from the loss period metric Type-P-One-Way-Loss-Period-Stream as
   follows:

This represents the total number of loss periods, and can be derived from the loss period metric Type-P-One-Way-Loss-Period-Stream as follows:

   Type-P-One-Way-Loss-Period-Total = maximum value of the first entry
   of the set of pairs, <loss period, loss>, representing the loss
   metric Type-P-One-Way-Loss-Period-Stream.

Type-P-One-Way-Loss-Period-Total = maximum value of the first entry of the set of pairs, <loss period, loss>, representing the loss metric Type-P-One-Way-Loss-Period-Stream.

   Note that this statistic does not describe the duration of each loss
   period itself.  If this statistic is large, it does not mean that the
   losses are more spread out than they are otherwise; one or more loss
   periods may include bursty losses.  This statistic is generally
   useful in gathering first order approximation of loss spread.

Note that this statistic does not describe the duration of each loss period itself. If this statistic is large, it does not mean that the losses are more spread out than they are otherwise; one or more loss periods may include bursty losses. This statistic is generally useful in gathering first order approximation of loss spread.

Koodli & Ravikanth           Informational                      [Page 9]

RFC 3357          One-way Loss Pattern Sample Metrics        August 2002

Koodli & Ravikanth Informational [Page 9] RFC 3357 One-way Loss Pattern Sample Metrics August 2002

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, length>, with the
   "loss period" entry ranging from 1 - Type-P-One-Way-Loss-Period-
   Total.  Thus the total number of pairs in this statistic equals
   Type-P-One-Way-Loss-Period-Total.  In each pair, the "length" is
   obtained by counting the number of pairs, <loss period, loss>, in the
   metric Type-P-One-Way-Loss-Period-Stream which have their first entry
   equal to "loss period."

This statistic is a sequence of pairs <loss period, length>, with the "loss period" entry ranging from 1 - Type-P-One-Way-Loss-Period- Total. Thus the total number of pairs in this statistic equals Type-P-One-Way-Loss-Period-Total. In each pair, the "length" is obtained by counting the number of pairs, <loss period, loss>, in the metric Type-P-One-Way-Loss-Period-Stream which have their first entry equal to "loss period."

   Since this statistic represents the number of packets lost in each
   loss period, it is an indicator of burstiness of each loss period.
   In conjunction with loss-period-total statistic, this statistic is
   generally useful in observing which loss periods are potentially more
   influential than others from a quality perspective.

Since this statistic represents the number of packets lost in each loss period, it is an indicator of burstiness of each loss period. In conjunction with loss-period-total statistic, this statistic is generally useful in observing which loss periods are potentially more 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 periods.  It
   takes the form of a set of pairs <loss period, inter-loss-period-
   length>, with the "loss period" entry ranging from 1 - Type-P-One-
   Way-Loss-Period-Total, and "inter-loss-period-length" is the loss
   distance between the last packet considered lost in "loss period"
   'i-1', and the first packet considered lost in "loss period" 'i',
   where 'i' ranges from 2 to Type-P-One-Way-Loss-Period-Total.  The
   "inter-loss-period-length" associated with the first "loss period" is
   defined to be zero.

This statistic measures distance between successive loss periods. It takes the form of a set of pairs <loss period, inter-loss-period- length>, with the "loss period" entry ranging from 1 - Type-P-One- Way-Loss-Period-Total, and "inter-loss-period-length" is the loss distance between the last packet considered lost in "loss period" 'i-1', and the first packet considered lost in "loss period" 'i', where 'i' ranges from 2 to Type-P-One-Way-Loss-Period-Total. The "inter-loss-period-length" associated with the first "loss period" is defined to be zero.

   This statistic allows one to consider, for example, two loss periods
   each of length greater than one (implying loss burst), but separated
   by a distance of 2 to belong to the same loss burst if such a
   consideration is deemed useful.  When the Inter-Loss-Period-Length
   between two bursty loss periods is smaller, it could affect the loss
   concealing ability of multimedia codecs since there is relatively
   smaller history.  When it is larger, an application may be able to
   rebuild its history which could dampen the effect of an impending
   loss (period).

This statistic allows one to consider, for example, two loss periods each of length greater than one (implying loss burst), but separated by a distance of 2 to belong to the same loss burst if such a consideration is deemed useful. When the Inter-Loss-Period-Length between two bursty loss periods is smaller, it could affect the loss concealing ability of multimedia codecs since there is relatively smaller history. When it is larger, an application may be able to rebuild its history which could dampen the effect of an impending loss (period).

6.5. Examples

6.5. Examples

   We continue with the same example as in Section 5.4.3.  The three
   statistics defined above will have the following values.

We continue with the same example as in Section 5.4.3. The three 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>},

Koodli & Ravikanth           Informational                     [Page 10]

RFC 3357          One-way Loss Pattern Sample Metrics        August 2002

Koodli & Ravikanth Informational [Page 10] RFC 3357 One-way Loss Pattern Sample Metrics August 2002

      there are 3 loss distances that violate the delta of 2.  Thus,
      Type-P-One-Way-Loss-Noticeable-Rate = 3/5 ((number of noticeable
      losses)/(number of total losses))

there are 3 loss distances that violate the delta of 2. Thus, Type-P-One-Way-Loss-Noticeable-Rate = 3/5 ((number of noticeable 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
      period,loss> pairs is 4.  Thus,

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

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

the lengths of individual loss periods are 1, 1, 1 and 2 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 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 =

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 =

         {<1,0>,<2,3>,<3,2>,<4,2>}

{<1,0>,<2,3>,<3,2>,<4,2>}

7. Security Considerations

7. Security Considerations

   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.

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.

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.

Koodli & Ravikanth           Informational                     [Page 11]

RFC 3357          One-way Loss Pattern Sample Metrics        August 2002

損失型見本測定基準2002年8月の片道のKoodli&Ravikanth情報[11ページ]のRFC3357

7.1. Denial of Service Attacks

7.1. サービス不能攻撃

   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, it could perturb
   the network under test, cause congestion, or at worst be a denial-
   of-service attack to the network under test.  Legitimate measurements
   must have their parameters selected carefully in order to avoid
   interfering with normal traffic in the network.

λがType-P損失距離の流れとType-P損失期間の流れのコントロールでテストパケットが送られるレートを指定して、したがって、不適当に大きい状態で設定されるなら、それは、テストでネットワークを混乱させるか、混雑を引き起こすか、または最悪の場合はテスト中のネットワークに対するサービスの否定攻撃であるかもしれません。 正統の測定値で、通常の交通を妨げるのを避けるためにネットワークで慎重にそれらのパラメタを選択しなければなりません。

7.2. Privacy / Confidentiality

7.2. プライバシー/秘密性

   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.

利用者データのプライバシーは関心ではありません、基本的さ以来、メートル法です。ユーザー情報を全く含まないテストパケットを使用することで実行されるつもりです。 パケットがユーザー情報を含んだとしても、派生している測定基準はユーザによって送られたデータを発表しません。

7.3. Integrity

7.3. 保全

   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

8. IANA問題

   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.

このドキュメントは、以来、特定のプロトコルを定義しないで、それをします。あらゆる周知の値を定義してください、そして、このドキュメントのためのIANA問題が全くありません。

9. Acknowledgements

9. 承認

   Matt Zekauskas provided insightful feedback and the text for the
   Security Considerations section.  Merike Kao helped revising the
   Security Considerations and the Abstract to conform with RFC
   guidelines.  We thank both of them.  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.

マットZekauskasは洞察に満ちたフィードバックとテキストをSecurity Considerations部に提供しました。 Merike花王は、RFCガイドラインに従うためにSecurity Considerationsと要約を改訂するのを助けました。 私たちはともに彼らに感謝します。 IETFミーティングの間、仕事を奨励するためのガイAlmes、およびコメントのためのバーン・パクソンをありがとうございます。 オスロのミーティングでスティーブGlassにプレゼンテーションを作ってくださってありがとうございます。

10. Normative References

10. 引用規格

   [1]  Almes, G., Kalindindi, S. and M. Zekauskas, "A One-way Packet
        Loss Metric for IPPM", RFC 2680, September 1999.

[1]AlmesとG.とKalindindiとS.とM.Zekauskas、「IPPMにおける、メートル法のA One-道のパケット損失」、RFC2680、1999年9月。

   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[2] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

Koodli & Ravikanth           Informational                     [Page 12]

RFC 3357          One-way Loss Pattern Sample Metrics        August 2002

損失型見本測定基準2002年8月の片道のKoodli&Ravikanth情報[12ページ]のRFC3357

   [3]  Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for
        IP Performance Metrics", RFC 2330, May 1998.

[3] パクソン、V.、Almes、G.、Mahdavi、J.、およびM.マシス(「IPパフォーマンス測定基準のための枠組み」、RFC2330)は1998がそうするかもしれません。

11. Informative References

11. 有益な参照

   [4]  J.-C. Bolot and A. vega Garcia, "The case for FEC-based error
        control for Packet Audio in the Internet", ACM Multimedia
        Systems, 1997.

[4] J.-C。 BolotとA.ベガガルシア、「インターネットのPacket AudioのためのFECベースの誤り制御のためのケース」、ACM Multimedia Systems、1997

   [5]  M. S. Borella, D. Swider, S. Uludag, and G. B. Brewster,
        "Internet Packet Loss:  Measurement and Implications for End-
        to-End QoS," Proceedings, International Conference on Parallel
        Processing, August 1998.

[5] M.S.Borella、D.Swider、S.Uludag、およびG.B.ブリュースター、「インターネットパケット損失:」 「終わりまでの終わりのQoSのための測定と含意」、議事、並列処理に関する国際会議、8月1998

   [6]  M. Handley, "An examination of MBONE performance", Technical
        Report, USC/ISI, ISI/RR-97-450, July 1997

[6] M.ハンドレー、「MBONE性能の試験」、Technical Report、USC/ISI、ISI/RR-97-450、1997年7月

   [7]  R. Koodli, "Scheduling Support for Multi-tier Quality of Service
        in Continuous Media Applications", PhD dissertation, Electrical
        and Computer Engineering Department, University of
        Massachusetts, Amherst, MA 01003, September 1997.

[7]R.Koodliと「連続したメディアアプリケーションにおけるマルチ層のサービスの質のスケジューリングサポート」と博士号論文とElectricalとComputer技術部、マサチューセッツ、アマースト、MA 01003人の大学(1997年9月)。

   [8]  J. Padhye, V. Firoiu, J. Kurose and D. Towsley, "Modeling TCP
        throughput:  a simple model and its empirical validation", in
        Proceedings of SIGCOMM'98, 1998.

[8]J.Padhye、V.Firoiu、J.黒瀬、およびD.Towsley、「モデルTCPスループット:」 SIGCOMMのProceedingsの「単純モデルとその実証的な合法化」1998 98年。

   [9]  J. Padhye, J. Kurose, D. Towsley and R. Koodli, "A TCP-friendly
        rate adjustment protocol for continuous media flows over best-
        effort networks", short paper presentation in ACM SIGMETRICS'99.
        Available as Umass Computer Science tech report from
        ftp://gaia.cs.umass.edu/pub/Padhye98-tcp-friendly-TR.ps.gz

[9] J.Padhye、J.黒瀬、D.TowsleyとR.Koodli、「連続したメディアのためのTCPに優しい料金の調整プロトコルは最も良い努力ネットワークの上を流れます」、ACM SIGMETRICS'99'の短期証券プレゼンテーション。 ftp://gaia.cs.umass.edu/pub/Padhye98-tcp-friendly-TR.ps.gz からのUmassのコンピュータのScienceの科学技術のレポートとして、利用可能です。

   [10] K. Sriram and W. Whitt, "Characterizing superposition arrival
        processes in packet multiplexers for voice and data", IEEE
        Journal on Selected Areas of Communication, pages 833-846,
        September 1986,

[10] K.SriramとW.Whitt、「重ね合わせ到着を特徴付けるのは声とデータのためにパケット多重化装置で処理します」、CommunicationのSelected Areasの上のIEEE Journal、833-846ページ、1986年9月

   [11] M. Yajnik, J. Kurose and D. Towsley, "Packet loss correlation in
        the MBONE multicast network", Proceedings of IEEE Global
        Internet, London, UK, November 1996.

[11] M.ヤジニークとJ.黒瀬とD.Towsley、「MBONEマルチキャストネットワークにおけるパケット損失相関関係」、IEEE GlobalインターネットのProceedings、ロンドンイギリス(1996年11月)。

Koodli & Ravikanth           Informational                     [Page 13]

RFC 3357          One-way Loss Pattern Sample Metrics        August 2002

損失型見本測定基準2002年8月の片道のKoodli&Ravikanth情報[13ページ]のRFC3357

Authors' Addresses

作者のアドレス

   Rajeev Koodli
   Communications Systems Lab
   Nokia Research Center
   313 Fairchild Drive
   Mountain View, CA 94043
   USA

Rajeev Koodli通信網研究室ノキアリサーチセンター313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)

   Phone: +1-650 625-2359
   Fax: +1 650 625-2502
   EMail: rajeev.koodli@nokia.com

以下に電話をしてください。 +1-650 625-2359Fax: +1 650 625-2502 メールしてください: rajeev.koodli@nokia.com

   Rayadurgam Ravikanth
   Axiowave Networks Inc.
   200 Nickerson Road
   Marlborough, MA 01752
   USA

Rayadurgam Ravikanth Axiowaveは株式会社200のNickerson Road MA01752マールバラ(米国)をネットワークでつなぎます。

   EMail: rravikanth@axiowave.com

メール: rravikanth@axiowave.com

Koodli & Ravikanth           Informational                     [Page 14]

RFC 3357          One-way Loss Pattern Sample Metrics        August 2002

損失型見本測定基準2002年8月の片道のKoodli&Ravikanth情報[14ページ]のRFC3357

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2002).  All Rights Reserved.

Copyright(C)インターネット協会(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.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   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.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Koodli & Ravikanth           Informational                     [Page 15]

Koodli&Ravikanth情報です。[15ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

hash-object

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る