rfc2680.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                           G. Almes
Request for Comments: 2680                                  S. Kalidindi
Category: Standards Track                                   M. Zekauskas
                                             Advanced Network & Services
                                                          September 1999


                 A One-way Packet Loss Metric for IPPM

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

1. Introduction

   This memo defines a metric for one-way packet loss across Internet
   paths.  It builds on notions introduced and discussed in the IPPM
   Framework document, RFC 2330 [1]; the reader is assumed to be
   familiar with that document.

   This memo is intended to be parallel in structure to a companion
   document for One-way Delay ("A One-way Delay Metric for IPPM") [2];
   the reader is assumed to be familiar with that document.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [5].
   Although RFC 2119 was written with protocols in mind, the key words
   are used in this document for similar reasons.  They are used to
   ensure the results of measurements from two different implementations
   are comparable, and to note instances when an implementation could
   perturb the network.

   The structure of the memo is as follows:

   +  A 'singleton' analytic metric, called Type-P-One-way-Loss, is
      introduced to measure a single observation of packet transmission
      or loss.





Almes, et al.               Standards Track                     [Page 1]

RFC 2680          One Way Packet Loss Metric for IPPM     September 1999


   +  Using this singleton metric, a 'sample', called Type-P-One-way-
      Loss-Poisson-Stream, is introduced to measure a sequence of
      singleton transmissions and/or losses measured at times taken from
      a Poisson process.

   +  Using this sample, several 'statistics' of the sample are defined
      and discussed.

   This progression from singleton to sample to statistics, with clear
   separation among them, is important.

   Whenever a technical term from the IPPM Framework document is first
   used in this memo, it will be tagged with a trailing asterisk.  For
   example, "term*" indicates that "term" is defined in the Framework.

1.1. Motivation:

   Understanding one-way packet loss of Type-P* packets from a source
   host* to a destination host is useful for several reasons:

   +  Some applications do not perform well (or at all) if end-to-end
      loss between hosts is large relative to some threshold value.

   +  Excessive packet loss may make it difficult to support certain
      real-time applications (where the precise threshold of "excessive"
      depends on the application).

   +  The larger the value of packet loss, the more difficult it is for
      transport-layer protocols to sustain high bandwidths.

   +  The sensitivity of real-time applications and of transport-layer
      protocols to loss become especially important when very large
      delay-bandwidth products must be supported.

   The measurement of one-way loss instead of round-trip loss is
   motivated by the following factors:

   +  In today's Internet, the path from a source to a destination may
      be different than the path from the destination back to the source
      ("asymmetric paths"), such that different sequences of routers are
      used for the forward and reverse paths.  Therefore round-trip
      measurements actually measure the performance of two distinct
      paths together.  Measuring each path independently highlights the
      performance difference between the two paths which may traverse
      different Internet service providers, and even radically different
      types of networks (for example, research versus commodity
      networks, or ATM versus packet-over-SONET).




Almes, et al.               Standards Track                     [Page 2]

RFC 2680          One Way Packet Loss Metric for IPPM     September 1999


   +  Even when the two paths are symmetric, they may have radically
      different performance characteristics due to asymmetric queueing.

   +  Performance of an application may depend mostly on the performance
      in one direction.  For example, a file transfer using TCP may
      depend more on the performance in the direction that data flows,
      rather than the direction in which acknowledgements travel.

   +  In quality-of-service (QoS) enabled networks, provisioning in one
      direction may be radically different than provisioning in the
      reverse direction, and thus the QoS guarantees differ.  Measuring
      the paths independently allows the verification of both
      guarantees.

   It is outside the scope of this document to say precisely how loss
   metrics would be applied to specific problems.

1.2. General Issues Regarding Time

   {Comment: the terminology below differs from that defined by ITU-T
   documents (e.g., G.810, "Definitions and terminology for
   synchronization networks" and I.356, "B-ISDN ATM layer cell transfer
   performance"), but is consistent with the IPPM Framework document.
   In general, these differences derive from the different backgrounds;
   the ITU-T documents historically have a telephony origin, while the
   authors of this document (and the Framework) have a computer systems
   background.  Although the terms defined below have no direct
   equivalent in the ITU-T definitions, after our definitions we will
   provide a rough mapping.  However, note one potential confusion: our
   definition of "clock" is the computer operating systems definition
   denoting a time-of-day clock, while the ITU-T definition of clock
   denotes a frequency reference.}

   Whenever a time (i.e., a moment in history) is mentioned here, it is
   understood to be measured in seconds (and fractions) relative to UTC.

   As described more fully in the Framework document, there are four
   distinct, but related notions of clock uncertainty:

   synchronization*

        Synchronization measures the extent to which two clocks agree on
        what time it is.  For example, the clock on one host might be
        5.4 msec ahead of the clock on a second host.  {Comment: A rough
        ITU-T equivalent is "time error".}






Almes, et al.               Standards Track                     [Page 3]

RFC 2680          One Way Packet Loss Metric for IPPM     September 1999


   accuracy*

        Accuracy measures the extent to which a given clock agrees with
        UTC.  For example, the clock on a host might be 27.1 msec behind
        UTC.  {Comment: A rough ITU-T equivalent is "time error from
        UTC".}

   resolution*

        Resolution measures the precision of a given clock.  For
        example, the clock on an old Unix host might advance only once
        every 10 msec, and thus have a resolution of only 10 msec.
        {Comment: A very rough ITU-T equivalent is "sampling period".}

   skew*

        Skew measures the change of accuracy, or of synchronization,
        with time.  For example, the clock on a given host might gain
        1.3 msec per hour and thus be 27.1 msec behind UTC at one time
        and only 25.8 msec an hour later.  In this case, we say that the
        clock of the given host has a skew of 1.3 msec per hour relative
        to UTC, which threatens accuracy.  We might also speak of the
        skew of one clock relative to another clock, which threatens
        synchronization.  {Comment: A rough ITU-T equivalent is "time
        drift".}

2. A Singleton Definition for One-way Packet Loss

2.1. Metric Name:

      Type-P-One-way-Packet-Loss

2.2. Metric Parameters:

      +  Src, the IP address of a host

      +  Dst, the IP address of a host

      +  T, a time

2.3. Metric Units:

   The value of a Type-P-One-way-Packet-Loss is either a zero
   (signifying successful transmission of the packet) or a one
   (signifying loss).






Almes, et al.               Standards Track                     [Page 4]

RFC 2680          One Way Packet Loss Metric for IPPM     September 1999


2.4. Definition:

   >>The *Type-P-One-way-Packet-Loss* from Src to Dst at T is 0<< means
   that Src sent the first bit of a Type-P packet to Dst at wire-time* T
   and that Dst received that packet.

   >>The *Type-P-One-way-Packet-Loss* from Src to Dst at T is 1<< means
   that Src sent the first bit of a type-P packet to Dst at wire-time T
   and that Dst did not receive that packet.

2.5. Discussion:

   Thus, Type-P-One-way-Packet-Loss is 0 exactly when Type-P-One-way-
   Delay is a finite value, and it is 1 exactly when Type-P-One-way-
   Delay is undefined.

   The following issues are likely to come up in practice:

   +  A given methodology will have to include a way to distinguish
      between a packet loss and a very large (but finite) delay.  As
      noted by Mahdavi and Paxson [3], simple upper bounds (such as the
      255 seconds theoretical upper bound on the lifetimes of IP
      packets [4]) could be used, but good engineering, including an
      understanding of packet lifetimes, will be needed in practice.
      {Comment: Note that, for many applications of these metrics, there
      may be no harm in treating a large delay as packet loss.  An audio
      playback packet, for example, that arrives only after the playback
      point may as well have been lost.}

   +  If the packet arrives, but is corrupted, then it is counted as
      lost.  {Comment: one is tempted to count the packet as received
      since corruption and packet loss are related but distinct
      phenomena.  If the IP header is corrupted, however, one cannot be
      sure about the source or destination IP addresses and is thus on
      shaky grounds about knowing that the corrupted received packet
      corresponds to a given sent test packet.  Similarly, if other
      parts of the packet needed by the methodology to know that the
      corrupted received packet corresponds to a given sent test packet,
      then such a packet would have to be counted as lost.  Counting
      these packets as lost but packet with corruption in other parts of
      the packet as not lost would be inconsistent.}

   +  If the packet is duplicated along the path (or paths) so that
      multiple non-corrupt copies arrive at the destination, then the
      packet is counted as received.

   +  If the packet is fragmented and if, for whatever reason,
      reassembly does not occur, then the packet will be deemed lost.



Almes, et al.               Standards Track                     [Page 5]