GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc3357

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

  1. 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.)
  1. it allows re-use of the methodologies specified for the singleton

metric with modifications whenever necessary

  1. 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:
  1. 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).
  1. At the Src host, select Src and Dst IP addresses, and form a test

packet of Type-P with these addresses.

  1. At the Dst host, arrange to receive the packet.
  1. At the Src host, place a timestamp in the prepared Type-P packet,

and send it towards Dst.

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

  1. 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.
  1. 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))
  1. 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
  1. 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>}
  1. 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc3357.txt · Last modified: 2002/08/14 17:03 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki