rfc2679.txt

RFC 的详细文档！

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


                    A One-way Delay Metric for IPPM

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

2. Introduction

   This memo defines a metric for one-way delay of packets 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 Packet Loss ("A One-way Packet Loss Metric for IPPM")
   [2].

   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 [6].
   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-Delay, will
      be introduced to measure a single observation of one-way delay.






Almes, et al.               Standards Track                     [Page 1]

RFC 2679            A One-way Delay Metric for IPPM       September 1999


   +  Using this singleton metric, a 'sample', called Type-P-One-way-
      Delay-Poisson-Stream, will be introduced to measure a sequence of
      singleton delays measured at times taken from a Poisson process.

   +  Using this sample, several 'statistics' of the sample will be
      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.

2.1. Motivation:

   One-way delay of a Type-P* packet 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
      delay between hosts is large relative to some threshold value.

   +  Erratic variation in delay makes it difficult (or impossible) to
      support many real-time applications.

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

   +  The minimum value of this metric provides an indication of the
      delay due only to propagation and transmission delay.

   +  The minimum value of this metric provides an indication of the
      delay that will likely be experienced when the path* traversed is
      lightly loaded.

   +  Values of this metric above the minimum provide an indication of
      the congestion present in the path.

   The measurement of one-way delay instead of round-trip delay 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



Almes, et al.               Standards Track                     [Page 2]

RFC 2679            A One-way Delay Metric for IPPM       September 1999


      different Internet service providers, and even radically different
      types of networks (for example, research versus commodity
      networks, or ATM versus packet-over-SONET).

   +  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 delay
   metrics would be applied to specific problems.

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









Almes, et al.               Standards Track                     [Page 3]

RFC 2679            A One-way Delay Metric for IPPM       September 1999


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

   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*

         measures the precision of a given clock.  For example, the
         clock on an old Unix host might tick 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*

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

3. A Singleton Definition for One-way Delay

3.1. Metric Name:

   Type-P-One-way-Delay

3.2. Metric Parameters:

   +  Src, the IP address of a host

   +  Dst, the IP address of a host

   +  T, a time






Almes, et al.               Standards Track                     [Page 4]

RFC 2679            A One-way Delay Metric for IPPM       September 1999


3.3. Metric Units:

   The value of a Type-P-One-way-Delay is either a real number, or an
   undefined (informally, infinite) number of seconds.

3.4. Definition:

   For a real number dT, >>the *Type-P-One-way-Delay* from Src to Dst at
   T is dT<< means that Src sent the first bit of a Type-P packet to Dst
   at wire-time* T and that Dst received the last bit of that packet at
   wire-time T+dT.

   >>The *Type-P-One-way-Delay* from Src to Dst at T is undefined
   (informally, infinite)<< 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.

   Suggestions for what to report along with metric values appear in
   Section 3.8 after a discussion of the metric, methodologies for
   measuring the metric, and error analysis.

3.5. Discussion:

   Type-P-One-way-Delay is a relatively simple analytic metric, and one
   that we believe will afford effective methods of measurement.

   The following issues are likely to come up in practice:

   +  Real delay values will be positive.  Therefore, it does not make
      sense to report a negative value as a real delay.  However, an
      individual zero or negative delay value might be useful as part of
      a stream when trying to discover a distribution of a stream of
      delay values.

   +  Since delay values will often be as low as the 100 usec to 10 msec
      range, it will be important for Src and Dst to synchronize very
      closely.  GPS systems afford one way to achieve synchronization to
      within several 10s of usec.  Ordinary application of NTP may allow
      synchronization to within several msec, but this depends on the
      stability and symmetry of delay properties among those NTP agents
      used, and this delay is what we are trying to measure.  A
      combination of some GPS-based NTP servers and a conservatively
      designed and deployed set of other NTP servers should yield good
      results, but this is yet to be tested.

   +  A given methodology will have to include a way to determine
      whether a delay value is infinite or whether it is merely very
      large (and the packet is yet to arrive at Dst).  As noted by



Almes, et al.               Standards Track                     [Page 5]

RFC 2679            A One-way Delay Metric for IPPM       September 1999


      Mahdavi and Paxson [4], simple upper bounds (such as the 255
      seconds theoretical upper bound on the lifetimes of IP packets
      [5]) 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, the
      harm in treating a large delay as infinite might be zero or very
      small.  A TCP data packet, for example, that arrives only after
      several multiples of the RTT may as well have been lost.}

   +  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, and the first copy to arrive
      determines the packet's one-way delay.

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

3.6. Methodologies:

   As with other Type-P-* metrics, the detailed methodology will depend
   on the Type-P (e.g., protocol number, UDP/TCP port number, size,
   precedence).

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

   +  Arrange that Src and Dst are synchronized; that is, that they have
      clocks that are very closely synchronized with each other and each
      fairly close to the actual time.

   +  At the Src host, select Src and Dst IP addresses, and form a test
      packet of Type-P with these addresses.  Any 'padding' portion of
      the packet needed only to make the test packet a given size should
      be filled with randomized bits to avoid a situation in which the
      measured delay is lower than it would otherwise be due to
      compression techniques along the path.

   +  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, take a
      timestamp as soon as possible upon the receipt of the packet.  By
      subtracting the two timestamps, an estimate of one-way delay can
      be computed.  Error analysis of a given implementation of the
      method must take into account the closeness of synchronization
      between Src and Dst.  If the delay between Src's timestamp and the



Almes, et al.               Standards Track                     [Page 6]

RFC 2679            A One-way Delay Metric for IPPM       September 1999


      actual sending of the packet is known, then the estimate could be
      adjusted by subtracting this amount; uncertainty in this value
      must be taken into account in error analysis.  Similarly, if the
      delay between the actual receipt of the packet and Dst's timestamp
      is known, then the estimate could be adjusted by subtracting this
      amount; uncertainty in this value must be taken into account in
      error analysis.  See the next section, "Errors and Uncertainties",
      for a more detailed discussion.

   +  If the packet fails to arrive within a reasonable period of time,
      the one-way delay is taken to be undefined (informally, infinite).
      Note that the threshold of 'reasonable' is a parameter of the
      methodology.

   Issues such as the packet format, the means by which Dst knows when
   to expect the test packet, and the means by which Src and Dst are
   synchronized are outside the scope of this document.  {Comment: We
   plan to document elsewhere our own work in describing such more
   detailed implementation techniques and we encourage others to as
   well.}

3.7. Errors and Uncertainties:

   The description of any specific measurement method should include an
   accounting and analysis of various sources of error or uncertainty.
   The Framework document provides general guidance on this point, but
   we note here the following specifics related to delay metrics:

   +  Errors or uncertainties due to uncertainties in the clocks of the
      Src and Dst hosts.

   +  Errors or uncertainties due to the difference between 'wire time'
      and 'host time'.