rfc2681.txt

来自「著名的RFC文档,其中有一些文档是已经翻译成中文的的.」· 文本 代码 · 共 1,124 行 · 第 1/3 页

   Delay values (see [2]) to form a Type-P-Round-trip-Delay value.  In
   order to form a Type-P-Round-trip-Delay value, the return packet must
   be triggered by the reception of a packet from Src.}

   {Comment: "ping" would qualify as a round-trip measure under this
   definition, with a Type-P of ICMP echo request/reply with 60-byte
   packets.  However, the uncertainties associated with a typical ping
   program must be analyzed as in the next section, including the type
   of reflecting point (a router may not handle an ICMP request in the
   fast path) and effects of load on the reflecting point.}








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


2.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 uncertainty in the clock of the Src
      host.

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

   +  Errors or uncertainties due to time required by the Dst to receive
      the packet from the Src and send the corresponding response.

   In addition, the loss threshold may affect the results.  Each of
   these are discussed in more detail below, along with a section
   ("Calibration") on accounting for these errors and uncertainties.

2.7.1. Errors or Uncertainties Related to Clocks

   The uncertainty in a measurement of round-trip delay is related, in
   part, to uncertainty in the clock of the Src host.  In the following,
   we refer to the clock used to measure when the packet was sent from
   Src as the source clock, and we refer to the observed time when the
   packet was sent by the source as Tinitial, and the observed time when
   the packet was received by the source as Tfinal.  Alluding to the
   notions of synchronization, accuracy, resolution, and skew mentioned
   in the Introduction, we note the following:

   +  While in one-way delay there is an issue of the synchronization of
      the source clock and the destination clock, in round-trip delay
      there is an (easier) issue of self-synchronization, as it were,
      between the source clock at the time the test packet is sent and
      the (same) source clock at the time the response packet is
      received.  Theoretically a very severe case of skew could threaten
      this.  In practice, the greater threat is anything that would
      cause a discontinuity in the source clock during the time between
      the taking of the initial and final timestamp.  This might happen,
      for example, with certain implementations of NTP.

   +  The accuracy of a clock is important only in identifying the time
      at which a given delay was measured.  Accuracy, per se, has no
      importance to the accuracy of the measurement of delay.






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


   +  The resolution of a clock adds to uncertainty about any time
      measured with it.  Thus, if the source clock has a resolution of
      10 msec, then this adds 10 msec of uncertainty to any time value
      measured with it.  We will denote the resolution of the source
      clock as Rsource.

   Taking these items together, we note that naive computation Tfinal-
   Tinitial will be off by 2*Rsource.

2.7.2. Errors or Uncertainties Related to Wire-time vs Host-time

   As we have defined round-trip delay, we would like to measure the
   time between when the test packet leaves the network interface of Src
   and when the corresponding response packet (completely) arrives at
   the network interface of Src, and we refer to these as "wire times".
   If the timings are themselves performed by software on Src, however,
   then this software can only directly measure the time between when
   Src grabs a timestamp just prior to sending the test packet and when
   it grabs a timestamp just after having received the response packet,
   and we refer to these two points as "host times".

   Another contributor to this problem is time spent at Dst between the
   receipt there of the test packet and the sending of the response
   packet.  Ideally, this time is zero; it is explored further in the
   next section.

   To the extent that the difference between wire time and host time is
   accurately known, this knowledge can be used to correct for host time
   measurements and the corrected value more accurately estimates the
   desired (wire time) metric.

   To the extent, however, that the difference between wire time and
   host time is uncertain, this uncertainty must be accounted for in an
   analysis of a given measurement method.  We denote by Hinitial an
   upper bound on the uncertainty in the difference between wire time
   and host time on the Src host in sending the test packet, and
   similarly define Hfinal for the difference on the Src host in
   receiving the response packet.  We then note that these problems
   introduce a total uncertainty of Hinitial + Hfinal.  This estimate of
   total wire-vs-host uncertainty should be included in the
   error/uncertainty analysis of any measurement implementation.

2.7.3. Errors or Uncertainties Related to Dst Producing a Response

   Any time spent by the destination host in receiving and recognizing
   the packet from Src, and then producing and sending the corresponding
   response adds additional error and uncertainty to the round-trip
   delay measurement.  The error equals the difference between the wire



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


   time the first bit of the packet is received by Dst and the wire time
   the first bit of the response is sent by Dst.  To the extent that
   this difference is accurately known, this knowledge can be used to
   correct the desired metric.  To the extent, however, that this
   difference is uncertain, this uncertainty must be accounted for in
   the error analysis of a measurement implementation. We denote this
   uncertainty by Hrefl.  This estimate of uncertainty should be
   included in the error/uncertainty analysis of any measurement
   implementation.

2.7.4. Calibration

   Generally, the measured values can be decomposed as follows:

       measured value = true value + systematic error + random error

   If the systematic error (the constant bias in measured values) can be
   determined, it can be compensated for in the reported results.

       reported value = measured value - systematic error

   therefore

       reported value = true value + random error

   The goal of calibration is to determine the systematic and random
   error generated by the instruments themselves in as much detail as
   possible.  At a minimum, a bound ("e") should be found such that the
   reported value is in the range (true value - e) to (true value + e)
   at least 95 percent of the time.  We call "e" the calibration error
   for the measurements.  It represents the degree to which the values
   produced by the measurement instrument are repeatable; that is, how
   closely an actual delay of 30 ms is reported as 30 ms.  {Comment: 95
   percent was chosen because (1) some confidence level is desirable to
   be able to remove outliers, which will be found in measuring any
   physical property; and (2) a particular confidence level should be
   specified so that the results of independent implementations can be
   compared.}

   From the discussion in the previous three sections, the error in
   measurements could be bounded by determining all the individual
   uncertainties, and adding them together to form

       2*Rsource + Hinitial + Hfinal + Hrefl.







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


   However, reasonable bounds on both the clock-related uncertainty
   captured by the first term and the host-related uncertainty captured
   by the last three terms should be possible by careful design
   techniques and calibrating the instruments using a known, isolated,
   network in a lab.

   The host-related uncertainties, Hinitial + Hfinal + Hrefl, could be
   bounded by connecting two instruments back-to-back with a high-speed
   serial link or isolated LAN segment.  In this case, repeated
   measurements are measuring the same round-trip delay.

   If the test packets are small, such a network connection has a
   minimal delay that may be approximated by zero.  The measured delay
   therefore contains only systematic and random error in the
   instrumentation.  The "average value" of repeated measurements is the
   systematic error, and the variation is the random error.

   One way to compute the systematic error, and the random error to a
   95% confidence is to repeat the experiment many times - at least
   hundreds of tests.  The systematic error would then be the median.
   The random error could then be found by removing the systematic error
   from the measured values.  The 95% confidence interval would be the
   range from the 2.5th percentile to the 97.5th percentile of these
   deviations from the true value.  The calibration error "e" could then
   be taken to be the largest absolute value of these two numbers, plus
   the clock-related uncertainty.  {Comment: as described, this bound is
   relatively loose since the uncertainties are added, and the absolute
   value of the largest deviation is used.  As long as the resulting
   value is not a significant fraction of the measured values, it is a
   reasonable bound.  If the resulting value is a significant fraction
   of the measured values, then more exact methods will be needed to
   compute the calibration error.}

   Note that random error is a function of measurement load.  For
   example, if many paths will be measured by one instrument, this might
   increase interrupts, process scheduling, and disk I/O (for example,
   recording the measurements), all of which may increase the random
   error in measured singletons.  Therefore, in addition to minimal load
   measurements to find the systematic error, calibration measurements
   should be performed with the same measurement load that the
   instruments will see in the field.

   We wish to reiterate that this statistical treatment refers to the
   calibration of the instrument; it is used to "calibrate the meter
   stick" and say how well the meter stick reflects reality.






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


   In addition to calibrating the instruments for finite delay, two
   checks should be made to ensure that packets reported as losses were
   really lost.  First, the threshold for loss should be verified.  In
   particular, ensure the "reasonable" threshold is reasonable: that it
   is very unlikely a packet will arrive after the threshold value, and
   therefore the number of packets lost over an interval is not
   sensitive to the error bound on measurements.  Second, consider the
   possibility that a packet arrives at the network interface, but is
   lost due to congestion on that interface or to other resource
   exhaustion (e.g. buffers) in the instrument.

2.8. Reporting the Metric:

   The calibration and context in which the metric is measured MUST be
   carefully considered, and SHOULD always be reported along with metric
   results.  We now present four items to consider: the Type-P of test
   packets, the threshold of infinite delay (if any), error calibration,
   and the path traversed by the test packets.  This list is not
   exhaustive; any additional information that could be useful in
   interpreting applications of the metrics should also be reported.

2.8.1. Type-P

   As noted in the Framework document [1], the value of the metric may
   depend on the type of IP packets used to make the measurement, or
   "type-P".  The value of Type-P-Round-trip-Delay could change if the
   protocol (UDP or TCP), port number, size, or arrangement for special
   treatment (e.g., IP precedence or RSVP) changes.  The exact Type-P
   used to make the measurements MUST be accurately reported.

2.8.2. Loss threshold

   In addition, the threshold (or methodology to distinguish) between a
   large finite delay and loss MUST be reported.

2.8.3. Calibration Results

   +  If the systematic error can be determined, it SHOULD be removed
      from the measured values.

   +  You SHOULD also report the calibration error, e, such that the
      true value is the reported value plus or minus e, with 95%
      confidence (see the last section.)

   +  If possible, the conditions under which a test packet with finite
      delay is reported as lost due to resource exhaustion on the
      measurement instrument SHOULD be reported.




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


2.8.4. Path

   Finally, the path traversed by the packet SHOULD be reported, if
   possible.  In general it is impractical to know the precise path a
   given packet takes through the network.  The precise path may be
   known for certain Type-P on short or stable paths.  For example, if
   Type-P includes the record route (or loose-source route) option in
   the IP header, and the path is short enough, and all routers* on the
   path support record (or loose-source) route, and the Dst host copies
   the path from Src to Dst into the corresponding reply packet, then
   the path will be precisely recorded.  This is impractical because the
   route must be short enough, many routers do not support (or are not
   configured for) record route, and use of this feature would often
   artificially worsen the performance observed by removing the packet
   from common-case processing.  However, partial information is still
   valuable context.  For example, if a host can choose between two
   links* (and hence two separate routes from Src to Dst), then the
   initial link used is valuable context.  {Comment: For example, with
   Merit's NetNow setup, a Src on one NAP can reach a Dst on another NAP
   by either of several different backbone networks.}

3. A Definition for Samples of Round-trip Delay

   Given the singleton metric Type-P-Round-trip-Delay, we now define one
   particular sample of such singletons.  The idea of the sample is to
   select a particular binding of the parameters Src, Dst, and Type-P,
   then define a sample of values of parameter T.  The means for
   defining the values of T is to select a beginning time T0, a final
   time Tf, and an average rate lambda, then define a pseudo-random
   Poisson process of rate lambda, whose values fall between T0 and Tf.
   The time interval between successive values of T will then average
   1/lambda.

   {Comment: Note that Poisson sampling is only one way of defining a
   sample.  Poisson has the advantage of limiting bias, but other
   methods of sampling might be appropriate for different situations.
   We encourage others who find such appropriate cases to use this
   general framework and submit their sampling method for
   standardization.}

3.1. Metric Name:

   Type-P-Round-trip-Delay-Poisson-Stream








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


3.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 in reciprocal seconds

3.3. Metric Units:

   A sequence of pairs; the elements of each pair are: