rfc2330.txt

RFC 的详细文档！

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


   a router used to further the definition of the handling of an RSVP-
   enabled packet might treat the router's packet queue as supporting
   bounded delay -- a contradictory assumption.  This is not to say that
   we make contradictory assumptions at the same time, but that two
   different parts of our work might refine the simpler base concept in
   two divergent ways for different purposes.

   {Comment: in more mathematical terms, we would say that the A-frame
   taken as a whole need not be consistent; but the set of particular
   A-frame elements used to define a particular metric must be.}


8. Empirically Specified Metrics

   There are useful performance and reliability metrics that do not fit
   so neatly into the A-frame, usually because the A-frame lacks the
   detail or power for dealing with them.  For example, "the best flow
   capacity achievable along a path using an RFC-2001-compliant TCP"
   would be good to be able to measure, but we have no analytical
   framework of sufficient richness to allow us to cast that flow
   capacity as an analytical metric.

   These notions can still be well specified by instead describing a
   reference methodology for measuring them.

   Such a metric will be called an 'empirically specified metric', or
   more simply, an empirical metric.

   Such empirical metrics should have three properties:

 +    we should have a clear definition for each in terms of Internet
      components,
 +    we should have at least one effective means to measure them, and
 +    to the extent possible, we should have an (necessarily incomplete)
      understanding of the metric in terms of the A-frame so that we can
      use our measurements to reason about the performance and
      reliability of A-frame components and of aggregations of A-frame
      components.













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


9. Two Forms of Composition


9.1. Spatial Composition of Metrics

   In some cases, it may be realistic and useful to define metrics in
   such a fashion that they exhibit spatial composition.

   By spatial composition, we mean a characteristic of some path
   metrics, in which the metric as applied to a (complete) path can also
   be defined for various subpaths, and in which the appropriate A-frame
   concepts for the metric suggest useful relationships between the
   metric applied to these various subpaths (including the complete
   path, the various cloud subpaths of a given path digest, and even
   single routers along the path).  The effectiveness of spatial
   composition depends:

 +    on the usefulness in analysis of these relationships as applied to
      the relevant A-frame components, and
 +    on the practical use of the corresponding relationships as applied
      to metrics and to measurement methodologies.

   {Comment: for example, consider some metric for delay of a 100-byte
   packet across a path P, and consider further a path digest <h0, e1,
   C1, ..., en, hn> of P.  The definition of such a metric might include
   a conjecture that the delay across P is very nearly the sum of the
   corresponding metric across the exchanges (ei) and clouds (Ci) of the
   given path digest.  The definition would further include a note on
   how a corresponding relation applies to relevant A-frame components,
   both for the path P and for the exchanges and clouds of the path
   digest.}

   When the definition of a metric includes a conjecture that the metric
   across the path is related to the metric across the subpaths of the
   path, that conjecture constitutes a claim that the metric exhibits
   spatial composition.  The definition should then include:















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


 +    the specific conjecture applied to the metric,
 +    a justification of the practical utility of the composition in
      terms of making accurate measurements of the metric on the path,
 +    a justification of the usefulness of the composition in terms of
      making analysis of the path using A-frame concepts more effective,
      and
 +    an analysis of how the conjecture could be incorrect.


9.2. Temporal Composition of Formal Models and Empirical Metrics

   In some cases, it may be realistic and useful to define metrics in
   such a fashion that they exhibit temporal composition.

   By temporal composition, we mean a characteristic of some path
   metric, in which the metric as applied to a path at a given time T is
   also defined for various times t0 < t1 < ... < tn < T, and in which
   the appropriate A-frame concepts for the metric suggests useful
   relationships between the metric applied at times t0, ..., tn and the
   metric applied at time T.  The effectiveness of temporal composition
   depends:

 +    on the usefulness in analysis of these relationships as applied to
      the relevant A-frame components, and
 +    on the practical use of the corresponding relationships as applied
      to metrics and to measurement methodologies.

   {Comment: for example, consider a  metric for the expected flow
   capacity across a path P during the five-minute period surrounding
   the time T, and suppose further that we have the corresponding values
   for each of the four previous five-minute periods t0, t1, t2, and t3.
   The definition of such a metric might include a conjecture that the
   flow capacity at time T can be estimated from a certain kind of
   extrapolation from the values of t0, ..., t3.  The definition would
   further include a note on how a corresponding relation applies to
   relevant A-frame components.

   Note: any (spatial or temporal) compositions involving flow capacity
   are likely to be subtle, and temporal compositions are generally more
   subtle than spatial compositions, so the reader should understand
   that the foregoing example is intentionally naive.}

   When the definition of a metric includes a conjecture that the metric
   across the path at a given time T is related to the metric across the
   path for a set of other times, that conjecture constitutes a claim
   that the metric exhibits temporal composition.  The definition should
   then include:




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


 +    the specific conjecture applied to the metric,
 +    a justification of the practical utility of the composition in
      terms of making accurate measurements of the metric on the path,
      and
 +    a justification of the usefulness of the composition in terms of
      making analysis of the path using A-frame concepts more effective.


10. Issues related to Time


10.1. Clock Issues

   Measurements of time lie at the heart of many Internet metrics.
   Because of this, it will often be crucial when designing a
   methodology for measuring a metric to understand the different types
   of errors and uncertainties introduced by imperfect clocks.  In this
   section we define terminology for discussing the characteristics of
   clocks and touch upon related measurement issues which need to be
   addressed by any sound methodology.

   The Network Time Protocol (NTP; RFC 1305) defines a nomenclature for
   discussing clock characteristics, which we will also use when
   appropriate [Mi92].  The main goal of NTP is to provide accurate
   timekeeping over fairly long time scales, such as minutes to days,
   while for measurement purposes often what is more important is
   short-term accuracy, between the beginning of the measurement and the
   end, or over the course of gathering a body of measurements (a
   sample).  This difference in goals sometimes leads to different
   definitions of terminology as well, as discussed below.

   To begin, we define a clock's "offset" at a particular moment as the
   difference between the time reported by the clock and the "true" time
   as defined by UTC.  If the clock reports a time Tc and the true time
   is Tt, then the clock's offset is Tc - Tt.

   We will refer to a clock as "accurate" at a particular moment if the
   clock's offset is zero, and more generally a clock's "accuracy" is
   how close the absolute value of the offset is to zero.  For NTP,
   accuracy also includes a notion of the frequency of the clock; for
   our purposes, we instead incorporate this notion into that of "skew",
   because we define accuracy in terms of a single moment in time rather
   than over an interval of time.

   A clock's "skew" at a particular moment is the frequency difference
   (first derivative of its offset with respect to true time) between
   the clock and true time.




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


   As noted in RFC 1305, real clocks exhibit some variation in skew.
   That is, the second derivative of the clock's offset with respect to
   true time is generally non-zero.  In keeping with RFC 1305, we define
   this quantity as the clock's "drift".

   A clock's "resolution" is the smallest unit by which the clock's time
   is updated.  It gives a lower bound on the clock's uncertainty.
   (Note that clocks can have very fine resolutions and yet be wildly
   inaccurate.)  Resolution is defined in terms of seconds.  However,
   resolution is relative to the clock's reported time and not to true
   time, so for example a resolution of 10 ms only means that the clock
   updates its notion of time in 0.01 second increments, not that this
   is the true amount of time between updates.

   {Comment: Systems differ on how an application interface to the clock
   reports the time on subsequent calls during which the clock has not
   advanced.  Some systems simply return the same unchanged time as
   given for previous calls.  Others may add a small increment to the
   reported time to maintain monotone-increasing timestamps.  For
   systems that do the latter, we do *not* consider these small
   increments when defining the clock's resolution.  They are instead an
   impediment to assessing the clock's resolution, since a natural
   method for doing so is to repeatedly query the clock to determine the
   smallest non-zero difference in reported times.}

   It is expected that a clock's resolution changes only rarely (for
   example, due to a hardware upgrade).

   There are a number of interesting metrics for which some natural
   measurement methodologies involve comparing times reported by two
   different clocks.  An example is one-way packet delay [AK97].  Here,
   the time required for a packet to travel through the network is
   measured by comparing the time reported by a clock at one end of the
   packet's path, corresponding to when the packet first entered the
   network, with the time reported by a clock at the other end of the
   path, corresponding to when the packet finished traversing the
   network.

   We are thus also interested in terminology for describing how two
   clocks C1 and C2 compare.  To do so, we introduce terms related to
   those above in which the notion of "true time" is replaced by the
   time as reported by clock C1.  For example, clock C2's offset
   relative to C1 at a particular moment is Tc2 - Tc1, the instantaneous
   difference in time reported by C2 and C1.  To disambiguate between
   the use of the terms to compare two clocks versus the use of the
   terms to compare to true time, we will in the former case use the
   phrase "relative".  So the offset defined earlier in this paragraph
   is the "relative offset" between C2 and C1.