rfc2330.txt

RFC 的详细文档！

Paxson, et. al.              Informational                      [Page 5]

RFC 2330          Framework for IP Performance Metrics          May 1998


 +    When a time is given, it will be expressed in UTC.

   Note that these points apply to the specifications for metrics and
   not, for example, to packet formats where octets will likely be used
   in preference/addition to bits.

   Finally, we note that some metrics may be defined purely in terms of
   other metrics; such metrics are call 'derived metrics'.


6.2. Measurement Methodology

   For a given set of well-defined metrics, a number of distinct
   measurement methodologies may exist.  A partial list includes:

 +    Direct measurement of a performance metric using injected test
      traffic.  Example: measurement of the round-trip delay of an IP
      packet of a given size over a given route at a given time.
 +    Projection of a metric from lower-level measurements.  Example:
      given accurate measurements of propagation delay and bandwidth for
      each step along a path, projection of the complete delay for the
      path for an IP packet of a given size.
 +    Estimation of a constituent metric from a set of more aggregated
      measurements.  Example: given accurate measurements of delay for a
      given one-hop path for IP packets of different sizes, estimation
      of propagation delay for the link of that one-hop path.
 +    Estimation of a given metric at one time from a set of related
      metrics at other times.  Example: given an accurate measurement of
      flow capacity at a past time, together with a set of accurate
      delay measurements for that past time and the current time, and
      given a model of flow dynamics, estimate the flow capacity that
      would be observed at the current time.

   This list is by no means exhaustive.  The purpose is to point out the
   variety of measurement techniques.

   When a given metric is specified, a given measurement approach might
   be noted and discussed.  That approach, however, is not formally part
   of the specification.

   A methodology for a metric should have the property that it is
   repeatable: if the methodology is used multiple times under identical
   conditions, it should result in consistent measurements.

   Backing off a little from the word 'identical' in the previous
   paragraph, we could more accurately use the word 'continuity' to
   describe a property of a given methodology: a methodology for a given
   metric exhibits continuity if, for small variations in conditions, it



Paxson, et. al.              Informational                      [Page 6]

RFC 2330          Framework for IP Performance Metrics          May 1998


   results in small variations in the resulting measurements.  Slightly
   more precisely, for every positive epsilon, there exists a positive
   delta, such that if two sets of conditions are within delta of each
   other, then the resulting measurements will be within epsilon of each
   other.  At this point, this should be taken as a heuristic driving
   our intuition about one kind of robustness property rather than as a
   precise notion.

   A metric that has at least one methodology that exhibits continuity
   is said itself to exhibit continuity.

   Note that some metrics, such as hop-count along a path, are integer-
   valued and therefore cannot exhibit continuity in quite the sense
   given above.

   Note further that, in practice, it may not be practical to know (or
   be able to quantify) the conditions relevant to a measurement at a
   given time.  For example, since the instantaneous load (in packets to
   be served) at a given router in a high-speed wide-area network can
   vary widely over relatively brief periods and will be very hard for
   an external observer to quantify, various statistics of a given
   metric may be more repeatable, or may better exhibit continuity.  In
   that case those particular statistics should be specified when the
   metric is specified.

   Finally, some measurement methodologies may be 'conservative' in the
   sense that the act of measurement does not modify, or only slightly
   modifies, the value of the performance metric the methodology
   attempts to measure.  {Comment: for example, in a wide-are high-speed
   network under modest load, a test using several small 'ping' packets
   to measure delay would likely not interfere (much) with the delay
   properties of that network as observed by others.  The corresponding
   statement about tests using a large flow to measure flow capacity
   would likely fail.}


6.3. Measurements, Uncertainties, and Errors

   Even the very best measurement methodologies for the very most well
   behaved metrics will exhibit errors.  Those who develop such
   measurement methodologies, however, should strive to:










Paxson, et. al.              Informational                      [Page 7]

RFC 2330          Framework for IP Performance Metrics          May 1998


 +    minimize their uncertainties/errors,
 +    understand and document the sources of uncertainty/error, and
 +    quantify the amounts of uncertainty/error.

   For example, when developing a method for measuring delay, understand
   how any errors in your clocks introduce errors into your delay
   measurement, and quantify this effect as well as you can.  In some
   cases, this will result in a requirement that a clock be at least up
   to a certain quality if it is to be used to make a certain
   measurement.

   As a second example, consider the timing error due to measurement
   overheads within the computer making the measurement, as opposed to
   delays due to the Internet component being measured.  The former is a
   measurement error, while the latter reflects the metric of interest.
   Note that one technique that can help avoid this overhead is the use
   of a packet filter/sniffer, running on a separate computer that
   records network packets and timestamps them accurately (see the
   discussion of 'wire time' below).  The resulting trace can then be
   analyzed to assess the test traffic, minimizing the effect of
   measurement host delays, or at least allowing those delays to be
   accounted for.  We note that this technique may prove beneficial even
   if the packet filter/sniffer runs on the same machine, because such
   measurements generally provide 'kernel-level' timestamping as opposed
   to less-accurate 'application-level' timestamping.

   Finally, we note that derived metrics (defined above) or metrics that
   exhibit spatial or temporal composition (defined below) offer
   particular occasion for the analysis of measurement uncertainties,
   namely how the uncertainties propagate (conceptually) due to the
   derivation or composition.


7. Metrics and the Analytical Framework

   As the Internet has evolved from the early packet-switching studies
   of the 1960s, the Internet engineering community has evolved a common
   analytical framework of concepts.  This analytical framework, or A-
   frame, used by designers and implementers of protocols, by those
   involved in measurement, and by those who study computer network
   performance using the tools of simulation and analysis, has great
   advantage to our work.  A major objective here is to generate network
   characterizations that are consistent in both analytical and
   practical settings, since this will maximize the chances that non-
   empirical network study can be better correlated with, and used to
   further our understanding of, real network behavior.





Paxson, et. al.              Informational                      [Page 8]

RFC 2330          Framework for IP Performance Metrics          May 1998


   Whenever possible, therefore, we would like to develop and leverage
   off of the A-frame.  Thus, whenever a metric to be specified is
   understood to be closely related to concepts within the A-frame, we
   will attempt to specify the metric in the A-frame's terms.  In such a
   specification we will develop the A-frame by precisely defining the
   concepts needed for the metric, then leverage off of the A-frame by
   defining the metric in terms of those concepts.

   Such a metric will be called an 'analytically specified metric' or,
   more simply, an analytical metric.

   {Comment: Examples of such analytical metrics might include:

propagation time of a link
     The time, in seconds, required by a single bit to travel from the
     output port on one Internet host across a single link to another
     Internet host.

bandwidth of a link for packets of size k
     The capacity, in bits/second, where only those bits of the IP
     packet are counted, for packets of size k bytes.

routeThe path, as defined in Section 5, from A to B at a given time.

hop count of a route
     The value 'n' of the route path.
     }

     Note that we make no a priori list of just what A-frame concepts
     will emerge in these specifications, but we do encourage their use
     and urge that they be carefully specified so that, as our set of
     metrics develops, so will a specified set of A-frame concepts
     technically consistent with each other and consonant with the
     common understanding of those concepts within the general Internet
     community.

     These A-frame concepts will be intended to abstract from actual
     Internet components in such a way that:

 +    the essential function of the component is retained,
 +    properties of the component relevant to the metrics we aim to
      create are retained,
 +    a subset of these component properties are potentially defined as
      analytical metrics, and







Paxson, et. al.              Informational                      [Page 9]

RFC 2330          Framework for IP Performance Metrics          May 1998


 +    those properties of actual Internet components not relevant to
      defining the metrics we aim to create are dropped.

   For example, when considering a router in the context of packet
   forwarding, we might model the router as a component that receives
   packets on an input link, queues them on a FIFO packet queue of
   finite size, employs tail-drop when the packet queue is full, and
   forwards them on an output link.  The transmission speed (in
   bits/second) of the input and output links, the latency in the router
   (in seconds), and the maximum size of the packet queue (in bits) are
   relevant analytical metrics.

   In some cases, such analytical metrics used in relation to a router
   will be very closely related to specific metrics of the performance
   of Internet paths.  For example, an obvious formula (L + P/B)
   involving the latency in the router (L), the packet size (in bits)
   (P), and the transmission speed of the output link (B) might closely
   approximate the increase in packet delay due to the insertion of a
   given router along a path.

   We stress, however, that well-chosen and well-specified A-frame
   concepts and their analytical metrics will support more general
   metric creation efforts in less obvious ways.

   {Comment: for example, when considering the flow capacity of a path,
   it may be of real value to be able to model each of the routers along
   the path as packet forwarders as above.  Techniques for estimating
   the flow capacity of a path might use the maximum packet queue size
   as a parameter in decidedly non-obvious ways.  For example, as the
   maximum queue size increases, so will the ability of the router to
   continuously move traffic along an output link despite fluctuations
   in traffic from an input link.  Estimating this increase, however,
   remains a research topic.}

   Note that, when we specify A-frame concepts and analytical metrics,
   we will inevitably make simplifying assumptions.  The key role of
   these concepts is to abstract the properties of the Internet
   components relevant to given metrics.  Judgement is required to avoid
   making assumptions that bias the modeling and metric effort toward
   one kind of design.

   {Comment: for example, routers might not use tail-drop, even though
   tail-drop might be easier to model analytically.}

   Finally, note that different elements of the A-frame might well make
   different simplifying assumptions.  For example, the abstraction of a
   router used to further the definition of path delay might treat the
   router's packet queue as a single FIFO queue, but the abstraction of