doc: Add RFC documents

1 files changed, 843 insertions, 0 deletions

diff --git a/doc/rfc/rfc3357.txt b/doc/rfc/rfc3357.txt
new file mode 100644
index 0000000..c1d2f2b
--- /dev/null
+++ b/doc/rfc/rfc3357.txt
@@ -0,0 +1,843 @@
+
+
+
+
+
+
+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
+
+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.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2002).  All Rights Reserved.
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koodli & Ravikanth           Informational                      [Page 1]
+
+RFC 3357          One-way Loss Pattern Sample Metrics        August 2002
+
+
+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
+
+
+
+
+
+
+
+
+
+
+
+
+Koodli & Ravikanth           Informational                      [Page 2]
+
+RFC 3357          One-way Loss Pattern Sample Metrics        August 2002
+
+
+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.
+
+   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
+
+   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
+
+   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
+
+
+   -  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 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.
+
+   In the following sections, we apply this approach to a particular
+   Internet behavior, namely the packet loss process.
+
+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.
+
+   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.
+
+   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
+
+   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
+
+
+
+
+
+
+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
+
+   f(P_i) is,
+
+   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.
+
+5. Definitions for Samples of One-way Loss Distance, and One-way Loss
+   Period
+
+5.1. Metric Names
+
+5.1.1. Type-P-One-Way-Loss-Distance-Stream
+
+5.1.2. Type-P-One-Way-Loss-Period-Stream
+
+5.2. Metric Parameters
+
+   Src,         the IP address of a host
+
+   Dst,         the IP address of a host
+
+   T0,          a time
+
+   Tf,          a time
+
+   lambda,      a rate of any sampling method chosen in reciprocal of
+                seconds
+
+5.3. Metric Units
+
+5.3.1. Type-P-One-Way-Loss-Distance-Stream
+
+   A sequence of pairs of the form <loss distance, loss>, where loss is
+   derived from the sequence of <time, loss> in [1], and loss distance
+   is either zero or a positive integer.
+
+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.
+
+
+
+
+
+Koodli & Ravikanth           Informational                      [Page 5]
+
+RFC 3357          One-way Loss Pattern Sample Metrics        August 2002
+
+
+5.4. Definitions
+
+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.
+
+   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
+
+   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.
+
+5.4.3. Examples
+
+   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>}
+
+   where T1, T2,..,T10 are in increasing order.
+
+
+
+
+
+
+
+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.
+
+   (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:
+
+   {<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:
+
+   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>}
+
+5.5. Methodologies
+
+   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:
+
+   -  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 Dst host, arrange to receive the packet.
+
+   -  At the Src host, place a timestamp in the prepared Type-P packet,
+      and send it towards Dst.
+
+   -  If the packet arrives within a reasonable period of time, the
+      one-way packet-loss is taken to be zero.
+
+
+
+
+
+
+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.
+
+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).
+
+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'.
+
+   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
+
+   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
+
+
+6. Statistics
+
+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".
+
+   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).
+
+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:
+
+   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.
+
+
+
+
+
+Koodli & Ravikanth           Informational                      [Page 9]
+
+RFC 3357          One-way Loss Pattern Sample Metrics        August 2002
+
+
+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."
+
+   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
+
+   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).
+
+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.
+
+   -  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>},
+
+
+
+
+
+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))
+
+   -  In Type-P-One-Way-Loss-Period-Stream
+
+         {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>},
+
+      the largest of the first entry in the sequence of <loss
+      period,loss> pairs is 4.  Thus,
+
+      Type-P-One-Way-Loss-Period-Total = 4
+
+   -  In Type-P-One-Way-Loss-Period-Stream
+
+         {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>},
+
+      the lengths of individual loss periods are 1, 1, 1 and 2
+      respectively.  Thus,
+
+      Type-P-One-Way-Loss-Period-Lengths =
+
+         {<1,1>,<2,1>,<3,1>,<4,2>}
+
+   -  In Type-P-One-Way-Loss-Period-Stream
+
+         {<0,0>,<1,1>,<0,0>,<0,0>,<2,1>,<0,0>,<3,1>,<0,0>,<4,1>,<4,1>},
+
+      the 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>}
+
+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.
+
+   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
+
+
+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, 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.
+
+7.2. Privacy / Confidentiality
+
+   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
+
+   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.
+
+9. Acknowledgements
+
+   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.
+
+10. Normative References
+
+   [1]  Almes, G., Kalindindi, S. and M. Zekauskas, "A One-way Packet
+        Loss Metric for IPPM", RFC 2680, September 1999.
+
+   [2]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
+        Levels", BCP 14, RFC 2119, March 1997.
+
+
+
+Koodli & Ravikanth           Informational                     [Page 12]
+
+RFC 3357          One-way Loss Pattern Sample Metrics        August 2002
+
+
+   [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
+        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.
+
+   [6]  M. Handley, "An examination of MBONE performance", Technical
+        Report, USC/ISI, ISI/RR-97-450, July 1997
+
+   [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.
+
+   [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.
+
+   [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
+
+   [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,
+
+   [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.
+
+
+
+
+
+
+
+
+
+
+
+Koodli & Ravikanth           Informational                     [Page 13]
+
+RFC 3357          One-way Loss Pattern Sample Metrics        August 2002
+
+
+Authors' Addresses
+
+   Rajeev Koodli
+   Communications Systems Lab
+   Nokia Research Center
+   313 Fairchild Drive
+   Mountain View, CA 94043
+   USA
+
+   Phone: +1-650 625-2359
+   Fax: +1 650 625-2502
+   EMail: rajeev.koodli@nokia.com
+
+
+   Rayadurgam Ravikanth
+   Axiowave Networks Inc.
+   200 Nickerson Road
+   Marlborough, MA 01752
+   USA
+
+   EMail: rravikanth@axiowave.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koodli & Ravikanth           Informational                     [Page 14]
+
+RFC 3357          One-way Loss Pattern Sample Metrics        August 2002
+
+
+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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Koodli & Ravikanth           Informational                     [Page 15]
+