rfc2681.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,124 行 · 第 1/3 页

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


                   A Round-trip Delay 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 round-trip delay of packets across
   Internet paths.  It builds on notions introduced and discussed in the
   IPPM Framework document, RFC 2330 [1], and follows closely the
   corresponding metric for One-way Delay ("A One-way Delay Metric for
   IPPM") [2]; the reader is assumed to be familiar with those
   documents.

   The memo was largely written by copying material from the One-way
   Delay metric.  The intention is that, where the two metrics are
   similar, they will be described with similar or identical text, and
   that where the two metrics differ, new or modified text will be used.

   This memo is intended to be parallel in structure to a future
   companion document for Packet Loss.

   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.





Almes, et al.               Standards Track                     [Page 1]

RFC 2681          Round-trip for Delay Metric for IPPM    September 1999


   The structure of the memo is as follows:

   +  A 'singleton' analytic metric, called Type-P-Round-trip-Delay,
      will be introduced to measure a single observation of round-trip
      delay.

   +  Using this singleton metric, a 'sample', called Type-P-Round-trip-
      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.

1.1. Motivation

   Round-trip 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 interactive 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.








Almes, et al.               Standards Track                     [Page 2]

RFC 2681          Round-trip for Delay Metric for IPPM    September 1999


   The measurement of round-trip delay instead of one-way delay has
   several weaknesses, summarized here:

   +  The Internet path from a source to a destination may differ from
      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.

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

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

   On the other hand, the measurement of round-trip delay has two
   specific advantages:

   +  Ease of deployment: unlike in one-way measurement, it is often
      possible to perform some form of round-trip delay measurement
      without installing measurement-specific software at the intended
      destination.  A variety of approaches are well-known, including
      use of ICMP Echo or of TCP-based methodologies (similar to those
      outlined in "IPPM Metrics for Measuring Connectivity" [4]).
      However, some approaches may introduce greater uncertainty in the
      time for the destination to produce a response (see
      Section 2.7.3).

   +  Ease of interpretation: in some circumstances, the round-trip time
      is in fact the quantity of interest. Deducing the round-trip time
      from matching one-way measurements and an assumption of the
      destination processing time is less direct and potentially less
      accurate.

1.2. General Issues Regarding Time

   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 2681          Round-trip for 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.

   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.

   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.

   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.

2. A Singleton Definition for Round-trip Delay

2.1. Metric Name:

   Type-P-Round-trip-Delay

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-Round-trip-Delay is either a real number, or an
   undefined (informally, infinite) number of seconds.





Almes, et al.               Standards Track                     [Page 4]

RFC 2681          Round-trip for Delay Metric for IPPM    September 1999


2.4. Definition:

   For a real number dT, >>the *Type-P-Round-trip-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, that Dst received that packet, then immediately
   sent a Type-P packet back to Src, and that Src received the last bit
   of that packet at wire-time T+dT.

   >>The *Type-P-Round-trip-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 (either Dst did not
   receive the packet, Dst did not send a Type-P packet in response, or)
   Src did not receive that response packet.

   >>The *Type-P-Round-trip-Delay between Src and Dst at T<< means
   either the *Type-P-Round-trip-Delay from Src to Dst at T or the
   *Type-P-Round-trip-Delay from Dst to Src at T.  When this notion is
   used, it is understood to be specifically ambiguous which host acts
   as Src and which as Dst.  {Comment: This ambiguity will usually be a
   small price to pay for being able to have one measurement, launched
   from either Src or Dst, rather than having two measurements.}

   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.

2.5. Discussion:

   Type-P-Round-trip-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:

   +  The timestamp values (T) for the time at which delays are measured
      should be fairly accurate in order to draw meaningful conclusions
      about the state of the network at a given T.  Therefore, Src
      should have an accurate knowledge of time-of-day.  NTP [3] affords
      one way to achieve time accuracy to within several milliseconds.
      Depending on the NTP server, higher accuracy may be achieved, for
      example when NTP servers make use of GPS systems as a time source.
      Note that NTP will adjust the instrument's clock.  If an
      adjustment is made between the time the initial timestamp is taken
      and the time the final timestamp is taken the adjustment will
      affect the uncertainty in the measured delay.  This uncertainty
      must be accounted for in the instrument's calibration.






Almes, et al.               Standards Track                     [Page 5]

RFC 2681          Round-trip for Delay Metric for IPPM    September 1999


   +  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
      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 so that multiple non-corrupt instances
      of the response arrive back at the source, then the packet is
      counted as received, and the first instance to arrive back at the
      source determines the packet's round-trip delay.

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

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

   +  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.  The test packet must have
      some identifying information so that the response to it can be
      identified by Src when Src receives the response; one means to do
      this is by placing the timestamp generated just before sending the
      test packet in the packet itself.

   +  At the Dst host, arrange to receive and respond to the test
      packet.  At the Src host, arrange to receive the corresponding
      response packet.








Almes, et al.               Standards Track                     [Page 6]

RFC 2681          Round-trip for Delay Metric for IPPM    September 1999


   +  At the Src host, take the initial timestamp and then send the
      prepared Type-P packet towards Dst.  Note that the timestamp could
      be placed inside the packet, or kept separately as long as the
      packet contains a suitable identifier so the received timestamp
      can be compared with the send timestamp.

   +  If the packet arrives at Dst, send a corresponding response packet
      back from Dst to Src as soon as possible.

   +  If the response packet arrives within a reasonable period of time,
      take the final timestamp as soon as possible upon the receipt of
      the packet.  By subtracting the two timestamps, an estimate of
      round-trip delay can be computed.  If the delay between the
      initial timestamp and the 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 response packet and final 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 round-trip 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 and the means by which Dst knows
   when to expect the test packet are outside the scope of this
   document.

   {Comment: Note that you cannot in general add two Type-P-One-way-