rfc2680.txt

RFC 的详细文档！


RFC 2680          One Way Packet Loss Metric for IPPM     September 1999


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, one possible methodology would proceed
   as follows:

   +  Arrange that Src and Dst have clocks that are synchronized with
      each other.  The degree of synchronization is a parameter of the
      methodology, and depends on the threshold used to determine loss
      (see below).

   +  At the Src host, select Src and Dst IP addresses, and form a test
      packet of Type-P with these addresses.

   +  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, the one-
      way packet-loss is taken to be zero.

   +  If the packet fails to arrive within a reasonable period of time,
      the one-way packet-loss is taken to be one.  Note that the
      threshold of "reasonable" here is a parameter of the methodology.

      {Comment: The definition of reasonable is intentionally vague, and
      is intended to indicate a value "Th" so large that any value in
      the closed interval [Th-delta, Th+delta] is an equivalent
      threshold for loss.  Here, delta encompasses all error in clock
      synchronization along the measured path.  If there is a single
      value after which the packet must be counted as lost, then we
      reintroduce the need for a degree of clock synchronization similar
      to that needed for one-way delay.  Therefore, if a measure of
      packet loss parameterized by a specific non-huge "reasonable"
      time-out value is needed, one can always measure one-way delay and
      see what percentage of packets from a given stream exceed a given
      time-out value.}

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



Almes, et al.               Standards Track                     [Page 6]

RFC 2680          One Way Packet Loss 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.

   For loss, there are three sources of error:

   +  Synchronization between clocks on Src and Dst.

   +  The packet-loss threshold (which is related to the synchronization
      between clocks).

   +  Resource limits in the network interface or software on the
      receiving instrument.

   The first two sources are interrelated and could result in a test
   packet with finite delay being reported as lost.  Type-P-One-way-
   Packet-Loss is 0 if the test packet does not arrive, or if it does
   arrive and the difference between Src timestamp and Dst timestamp is
   greater than the "reasonable period of time", or loss threshold.  If
   the clocks are not sufficiently synchronized, the loss threshold may
   not be "reasonable" - the packet may take much less time to arrive
   than its Src timestamp indicates.  Similarly, if the loss threshold
   is set too low, then many packets may be counted as lost.  The loss
   threshold must be high enough, and the clocks synchronized well
   enough so that a packet that arrives is rarely counted as lost.  (See
   the discussions in the previous two sections.)

   Since the sensitivity of packet loss measurement to lack of clock
   synchronization is less than for delay, we refer the reader to the
   treatment of synchronization errors in the One-way Delay metric [2]
   for more details.

   The last source of error, resource limits, cause the packet to be
   dropped by the measurement instrument, and counted as lost when in
   fact the network delivered the packet in reasonable time.

   The measurement instruments should be calibrated such that the loss
   threshold is reasonable for application of the metrics and the clocks
   are synchronized enough so the loss threshold remains reasonable.

   In addition, the instruments should be checked to ensure the that the
   possibility a packet arrives at the network interface, but is lost
   due to congestion on the interface or to other resource exhaustion
   (e.g., buffers) on the instrument is low.





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


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: Type-P of the test
   packets, the loss threshold, instrument 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-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.

2.8.2. Loss threshold

   The threshold (or methodology to distinguish) between a large finite
   delay and loss MUST be reported.

2.8.3. Calibration results

   The degree of synchronization between the Src and Dst clocks MUST be
   reported.  If possible, possibility that a test packet that arrives
   at the Dst network interface is reported as lost due to resource
   exhaustion on Dst SHOULD be reported.

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



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


   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 One-way Packet Loss

   Given the singleton metric Type-P-One-way-Packet-Loss, 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-One-way-Packet-Loss-Poisson-Stream

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:

   +  T, a time, and

   +  L, either a zero or a one






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


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

3.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-Packet-Loss at
   this time.  The value of the sample is the sequence made up of the
   resulting <time, loss> pairs.  If there are no such pairs, the
   sequence is of length zero and the sample is said to be empty.

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

   Since a pseudo-random number sequence is employed, the sequence of
   times, and hence the value of the sample, is not fully specified.
   Pseudo-random number generators of good quality will be needed to
   achieve the desired qualities.

   The sample is defined in terms of a Poisson process both to avoid the
   effects of self-synchronization and also capture a sample that is
   statistically as unbiased as possible.  The Poisson process is used
   to schedule the delay measurements.  The test packets will generally
   not arrive at Dst according to a Poisson distribution, since they are
   influenced by the network.

   {Comment: there is, of course, no claim that real Internet traffic
   arrives according to a Poisson arrival process.

   It is important to note that, in contrast to this metric, loss rates
   observed by transport connections do not reflect unbiased samples.
   For example, TCP transmissions both (1) occur in bursts, which can




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