rfc2330.txt

RFC 的详细文档！

Network Working Group                                          V. Paxson
Request for Comments: 2330                Lawrence Berkeley National Lab
Category: Informational                                         G. Almes
                                             Advanced Network & Services
                                                              J. Mahdavi
                                                               M. Mathis
                                         Pittsburgh Supercomputer Center
                                                                May 1998


                  Framework for IP Performance Metrics


1. Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.


2. Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

Table of Contents

   1.  STATUS OF THIS MEMO.............................................1
   2.  COPYRIGHT NOTICE................................................1
   3.  INTRODUCTION....................................................2
   4.  CRITERIA FOR IP PERFORMANCE METRICS.............................3
   5.  TERMINOLOGY FOR PATHS AND CLOUDS................................4
   6.  FUNDAMENTAL CONCEPTS............................................5
     6.1  Metrics......................................................5
     6.2  Measurement Methodology......................................6
     6.3  Measurements, Uncertainties, and Errors......................7
   7.  METRICS AND THE ANALYTICAL FRAMEWORK............................8
   8.  EMPIRICALLY SPECIFIED METRICS..................................11
   9.  TWO FORMS OF COMPOSITION.......................................12
     9.1  Spatial Composition of Metrics..............................12
     9.2  Temporal Composition of Formal Models and Empirical Metrics.13
   10.  ISSUES RELATED TO TIME........................................14
     10.1  Clock Issues...............................................14
     10.2  The Notion of "Wire Time"..................................17
   11. SINGLETONS, SAMPLES, AND STATISTICS............................19
     11.1  Methods of Collecting Samples..............................20
       11.1.1 Poisson Sampling........................................21
       11.1.2 Geometric Sampling......................................22
       11.1.3 Generating Poisson Sampling Intervals...................22



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


     11.2  Self-Consistency...........................................24
     11.3  Defining Statistical Distributions.........................25
     11.4  Testing For Goodness-of-Fit................................27
   12. AVOIDING STOCHASTIC METRICS....................................28
   13. PACKETS OF TYPE P..............................................29
   14. INTERNET ADDRESSES VS. HOSTS...................................30
   15. STANDARD-FORMED PACKETS........................................30
   16. ACKNOWLEDGEMENTS...............................................31
   17. SECURITY CONSIDERATIONS........................................31
   18. APPENDIX.......................................................32
   19. REFERENCES.....................................................38
   20. AUTHORS' ADDRESSES.............................................39
   21. FULL COPYRIGHT STATEMENT.......................................40


3. Introduction

   The purpose of this memo is to define a general framework for
   particular metrics to be developed by the IETF's IP Performance
   Metrics effort, begun by the Benchmarking Methodology Working Group
   (BMWG) of the Operational Requirements Area, and being continued by
   the IP Performance Metrics Working Group (IPPM) of the Transport
   Area.

   We begin by laying out several criteria for the metrics that we
   adopt.  These criteria are designed to promote an IPPM effort that
   will maximize an accurate common understanding by Internet users and
   Internet providers of the performance and reliability both of end-
   to-end paths through the Internet and of specific 'IP clouds' that
   comprise portions of those paths.

   We next define some Internet vocabulary that will allow us to speak
   clearly about Internet components such as routers, paths, and clouds.

   We then define the fundamental concepts of 'metric' and 'measurement
   methodology', which allow us to speak clearly about measurement
   issues.  Given these concepts, we proceed to discuss the important
   issue of measurement uncertainties and errors, and develop a key,
   somewhat subtle notion of how they relate to the analytical framework
   shared by many aspects of the Internet engineering discipline.  We
   then introduce the notion of empirically defined metrics, and finish
   this part of the document with a general discussion of how metrics
   can be 'composed'.

   The remainder of the document deals with a variety of issues related
   to defining sound metrics and methodologies:  how to deal with
   imperfect clocks; the notion of 'wire time' as distinct from 'host
   time'; how to aggregate sets of singleton metrics into samples and



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


   derive sound statistics from those samples; why it is recommended to
   avoid thinking about Internet properties in probabilistic terms (such
   as the probability that a packet is dropped), since these terms often
   include implicit assumptions about how the network behaves; the
   utility of defining metrics in terms of packets of a generic type;
   the benefits of preferring IP addresses to DNS host names; and the
   notion of 'standard-formed' packets.  An appendix discusses the
   Anderson-Darling test for gauging whether a set of values matches a
   given statistical distribution, and gives C code for an
   implementation of the test.

   In some sections of the memo, we will surround some commentary text
   with the brackets {Comment: ... }.  We stress that this commentary is
   only commentary, and is not itself part of the framework document or
   a proposal of particular metrics.  In some cases this commentary will
   discuss some of the properties of metrics that might be envisioned,
   but the reader should assume that any such discussion is intended
   only to shed light on points made in the framework document, and not
   to suggest any specific metrics.


4. Criteria for IP Performance Metrics

   The overarching goal of the IP Performance Metrics effort is to
   achieve a situation in which users and providers of Internet
   transport service have an accurate common understanding of the
   performance and reliability of the Internet component 'clouds' that
   they use/provide.

   To achieve this, performance and reliability metrics for paths
   through the Internet must be developed.  In several IETF meetings
   criteria for these metrics have been specified:

 +    The metrics must be concrete and well-defined,
 +    A methodology for a metric should have the property that it is
      repeatable: if the methodology is used multiple times under
      identical conditions, the same measurements should result in the
      same measurements.
 +    The metrics must exhibit no bias for IP clouds implemented with
      identical technology,
 +    The metrics must exhibit understood and fair bias for IP clouds
      implemented with non-identical technology,
 +    The metrics must be useful to users and providers in understanding
      the performance they experience or provide,







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


 +    The metrics must avoid inducing artificial performance goals.


5. Terminology for Paths and Clouds

   The following list defines terms that need to be precise in the
   development of path metrics.  We begin with low-level notions of
   'host', 'router', and 'link', then proceed to define the notions of
   'path', 'IP cloud', and 'exchange' that allow us to segment a path
   into relevant pieces.

   host A computer capable of communicating using the Internet
        protocols; includes "routers".

   link A single link-level connection between two (or more) hosts;
        includes leased lines, ethernets, frame relay clouds, etc.

   routerA host which facilitates network-level communication between
        hosts by forwarding IP packets.

   path A sequence of the form < h0, l1, h1, ..., ln, hn >, where n >=
        0, each hi is a host, each li is a link between hi-1 and hi,
        each h1...hn-1 is a router.  A pair <li, hi> is termed a 'hop'.
        In an appropriate operational configuration, the links and
        routers in the path facilitate network-layer communication of
        packets from h0 to hn.  Note that path is a unidirectional
        concept.

   subpath
        Given a path, a subpath is any subsequence of the given path
        which is itself a path.  (Thus, the first and last element of a
        subpath is a host.)

   cloudAn undirected (possibly cyclic) graph whose vertices are routers
        and whose edges are links that connect pairs of routers.
        Formally, ethernets, frame relay clouds, and other links that
        connect more than two routers are modelled as fully-connected
        meshes of graph edges.  Note that to connect to a cloud means to
        connect to a router of the cloud over a link; this link is not
        itself part of the cloud.

   exchange
        A special case of a link, an exchange directly connects either a
        host to a cloud and/or one cloud to another cloud.

   cloud subpath
        A subpath of a given path, all of whose hosts are routers of a
        given cloud.



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


   path digest
        A sequence of the form < h0, e1, C1, ..., en, hn >, where n >=
        0, h0 and hn are hosts, each e1 ... en is an exchange, and each
        C1 ... Cn-1 is a cloud subpath.

6. Fundamental Concepts


6.1. Metrics

   In the operational Internet, there are several quantities related to
   the performance and reliability of the Internet that we'd like to
   know the value of.  When such a quantity is carefully specified, we
   term the quantity a metric.  We anticipate that there will be
   separate RFCs for each metric (or for each closely related group of
   metrics).

   In some cases, there might be no obvious means to effectively measure
   the metric; this is allowed, and even understood to be very useful in
   some cases.  It is required, however, that the specification of the
   metric be as clear as possible about what quantity is being
   specified.  Thus, difficulty in practical measurement is sometimes
   allowed, but ambiguity in meaning is not.

   Each metric will be defined in terms of standard units of
   measurement.  The international metric system will be used, with the
   following points specifically noted:

 +    When a unit is expressed in simple meters (for distance/length) or
      seconds (for duration), appropriate related units based on
      thousands or thousandths of acceptable units are acceptable.
      Thus, distances expressed in kilometers (km), durations expressed
      in milliseconds (ms), or microseconds (us) are allowed, but not
      centimeters (because the prefix is not in terms of thousands or
      thousandths).
 +    When a unit is expressed in a combination of units, appropriate
      related units based on thousands or thousandths of acceptable
      units are acceptable, but all such thousands/thousandths must be
      grouped at the beginning.  Thus, kilo-meters per second (km/s) is
      allowed, but meters per millisecond is not.
 +    The unit of information is the bit.
 +    When metric prefixes are used with bits or with combinations
      including bits, those prefixes will have their metric meaning
      (related to decimal 1000), and not the meaning conventional with
      computer storage (related to decimal 1024).  In any RFC that
      defines a metric whose units include bits, this convention will be
      followed and will be repeated to ensure clarity for the reader.