rfc2679.txt

RFC 的详细文档！

   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.

3.7.1. Errors or uncertainties related to Clocks

   The uncertainty in a measurement of one-way delay is related, in
   part, to uncertainties in the clocks of the Src and Dst hosts.  In
   the following, we refer to the clock used to measure when the packet
   was sent from Src as the source clock, we refer to the clock used to
   measure when the packet was received by Dst as the destination clock,
   we refer to the observed time when the packet was sent by the source
   clock as Tsource, and the observed time when the packet was received
   by the destination clock as Tdest.  Alluding to the notions of



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


   synchronization, accuracy, resolution, and skew mentioned in the
   Introduction, we note the following:

   +  Any error in the synchronization between the source clock and the
      destination clock will contribute to error in the delay
      measurement.  We say that the source clock and the destination
      clock have a synchronization error of Tsynch if the source clock
      is Tsynch ahead of the destination clock.  Thus, if we know the
      value of Tsynch exactly, we could correct for clock
      synchronization by adding Tsynch to the uncorrected value of
      Tdest-Tsource.

   +  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.  When
      computing delays, we are interested only in the differences
      between clock values, not the values themselves.

   +  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 and the destination clock as Rsource and Rdest,
      respectively.

   +  The skew of a clock is not so much an additional issue as it is a
      realization of the fact that Tsynch is itself a function of time.
      Thus, if we attempt to measure or to bound Tsynch, this needs to
      be done periodically.  Over some periods of time, this function
      can be approximated as a linear function plus some higher order
      terms; in these cases, one option is to use knowledge of the
      linear component to correct the clock.  Using this correction, the
      residual Tsynch is made smaller, but remains a source of
      uncertainty that must be accounted for.  We use the function
      Esynch(t) to denote an upper bound on the uncertainty in
      synchronization.  Thus, |Tsynch(t)| <= Esynch(t).

   Taking these items together, we note that naive computation Tdest-
   Tsource will be off by Tsynch(t) +/- (Rsource + Rdest).  Using the
   notion of Esynch(t), we note that these clock-related problems
   introduce a total uncertainty of Esynch(t)+ Rsource + Rdest.  This
   estimate of total clock-related uncertainty should be included in the
   error/uncertainty analysis of any measurement implementation.








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


3.7.2. Errors or uncertainties related to Wire-time vs Host-time

   As we have defined one-way delay, we would like to measure the time
   between when the test packet leaves the network interface of Src and
   when it (completely) arrives at the network interface of Dst, and we
   refer to these as "wire times."  If the timings are themselves
   performed by software on Src and Dst, 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 Dst grabs a timestamp
   just after having received the test packet, and we refer to these two
   points as "host times".

   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 Hsource an
   upper bound on the uncertainty in the difference between wire time
   and host time on the Src host, and similarly define Hdest for the Dst
   host.  We then note that these problems introduce a total uncertainty
   of Hsource+Hdest.  This estimate of total wire-vs-host uncertainty
   should be included in the error/uncertainty analysis of any
   measurement implementation.

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



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


   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; (2) a particular confidence level should be
   specified so that the results of independent implementations can be
   compared; and (3) even with a prototype user-level implementation,
   95% was loose enough to exclude outliers.}

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

       Esynch(t) + Rsource + Rdest + Hsource + Hdest.

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

   For example, the clock-related uncertainties are greatly reduced
   through the use of a GPS time source.  The sum of Esynch(t) + Rsource
   + Rdest is small, and is also bounded for the duration of the
   measurement because of the global time source.

   The host-related uncertainties, Hsource + Hdest, 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 one-way 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



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


   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.

   In addition to calibrating the instruments for finite one-way 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.

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

3.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-One-way-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.




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


3.8.2. Loss threshold

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

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

3.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.  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, 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.}

4. A Definition for Samples of One-way Delay

   Given the singleton metric Type-P-One-way-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





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


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

4.1. Metric Name:

   Type-P-One-way-Delay-Poisson-Stream

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

4.3. Metric Units:

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

   +  T, a time, and

   +  dT, either a real number or an undefined number of seconds.

   The values of T in the sequence are monotonic increasing.  Note that
   T would be a valid parameter to Type-P-One-way-Delay, and that dT
   would be a valid value of Type-P-One-way-Delay.

4.4. Definition:

   Given T0, Tf, and lambda, we compute a pseudo-random Poisson process
   beginning at or before T0, with average arrival rate lambda, and
   ending at or after Tf.  Those time values greater than or equal to T0
   and less than or equal to Tf are then selected.  At each of the times
   in this process, we obtain the value of Type-P-One-way-Delay at this
   time.  The value of the sample is the sequence made up of the
   resulting <time, delay> pairs.  If there are no such pairs, the



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


   sequence is of length zero and the sample is said to be empty.

4.5. Discussion:

   The reader should be familiar with the in-depth discussion of Poisson
   sampling in the Framework document [1], which includes methods to
   compute and verify the pseudo-random Poisson process.

   We specifically do not constrain the value of lambda, except to note
   the extremes.  If the rate is too large, then the measurement traffic
   will perturb the network, and itself cause congestion.  If the rate
   is too small, then you might not capture interesting network
   behavior.  {Comment: We expect to document our experiences with, and
   suggestions for, lambda elsewhere, culminating in a "best current
   practices" document.}