rfc3148.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 900 行 · 第 1/3 页

Network Working Group                                          M. Mathis
Request for Comments: 3148              Pittsburgh Supercomputing Center
Category: Informational                                        M. Allman
                                                          BBN/NASA Glenn
                                                               July 2001


   A Framework for Defining Empirical Bulk Transfer Capacity Metrics

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.

Copyright Notice

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

Abstract

   This document defines a framework for standardizing multiple BTC
   (Bulk Transport Capacity) metrics that parallel the permitted
   transport diversity.

1   Introduction

   Bulk Transport Capacity (BTC) is a measure of a network's ability to
   transfer significant quantities of data with a single congestion-
   aware transport connection (e.g., TCP).  The intuitive definition of
   BTC is the expected long term average data rate (bits per second) of
   a single ideal TCP implementation over the path in question.
   However, there are many congestion control algorithms (and hence
   transport implementations) permitted by IETF standards.  This
   diversity in transport algorithms creates a difficulty for
   standardizing BTC metrics because the allowed diversity is sufficient
   to lead to situations where different implementations will yield
   non-comparable measures -- and potentially fail the formal tests for
   being a metric.

   Two approaches are used.  First, each BTC metric must be much more
   tightly specified than the typical IETF protocol.  Second, each BTC
   methodology is expected to collect some ancillary metrics which are
   potentially useful to support analytical models of BTC.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].  Although



Mathis, et al.               Informational                      [Page 1]

RFC 3148      Framework for Defining Empirical BTC Metrics     July 2001


   [RFC2119] was written with protocols in mind, the key words are used
   in this document for similar reasons.  They are used to ensure that
   each BTC methodology defined contains specific pieces of information.

   Bulk Transport Capacity (BTC) is a measure of a network's ability to
   transfer significant quantities of data with a single congestion-
   aware transport connection (e.g., TCP).  For many applications the
   BTC of the underlying network dominates the overall elapsed time for
   the application to run and thus dominates the performance as
   perceived by a user.  Examples of such applications include FTP, and
   the world wide web when delivering large images or documents.  The
   intuitive definition of BTC is the expected long term average data
   rate (bits per second) of a single ideal TCP implementation over the
   path in question.  The specific definition of the bulk transfer
   capacity that MUST be reported by a BTC tool is:

      BTC = data_sent / elapsed_time

   where "data_sent" represents the unique "data" bits transfered (i.e.,
   not including header bits or emulated header bits).  Also note that
   the amount of data sent should only include the unique number of bits
   transmitted (i.e., if a particular packet is retransmitted the data
   it contains should be counted only once).

   Central to the notion of bulk transport capacity is the idea that all
   transport protocols should have similar responses to congestion in
   the Internet.  Indeed the only form of equity significantly deployed
   in the Internet today is that the vast majority of all traffic is
   carried by TCP implementations sharing common congestion control
   algorithms largely due to a shared developmental heritage.

   [RFC2581] specifies the standard congestion control algorithms used
   by TCP implementations.  Even though this document is a (proposed)
   standard, it permits considerable latitude in implementation.  This
   latitude is by design, to encourage ongoing evolution in congestion
   control algorithms.

   This legal diversity in congestion control algorithms creates a
   difficulty for standardizing BTC metrics because the allowed
   diversity is sufficient to lead to situations where different
   implementations will yield non-comparable measures -- and potentially
   fail the formal tests for being a metric.

   There is also evidence that most TCP implementations exhibit non-
   linear performance over some portion of their operating region.  It
   is possible to construct simple simulation examples where incremental
   improvements to a path (such as raising the link data rate) results
   in lower overall TCP throughput (or BTC) [Mat98].



Mathis, et al.               Informational                      [Page 2]

RFC 3148      Framework for Defining Empirical BTC Metrics     July 2001


   We believe that such non-linearity reflects weakness in our current
   understanding of congestion control and is present to some extent in
   all TCP implementations and BTC metrics.  Note that such non-
   linearity (in either TCP or a BTC metric) is potentially problematic
   in the market because investment in capacity might actually reduce
   the perceived quality of the network.  Ongoing research in congestion
   dynamics has some hope of mitigating or modeling the these non-
   linearities.

   Related areas, including integrated services [RFC1633,RFC2216],
   differentiated services [RFC2475] and Internet traffic analysis
   [MSMO97,PFTK98,Pax97b,LM97] are all currently receiving significant
   attention from the research community.  It is likely that we will see
   new experimental congestion control algorithms in the near future.
   In addition, Explicit Congestion Notification (ECN) [RFC2481] is
   being tested for Internet deployment.  We do not yet know how any of
   these developments might affect BTC metrics, and thus the BTC
   framework and metrics may need to be revisited in the future.

   This document defines a framework for standardizing multiple BTC
   metrics that parallel the permitted transport diversity.  Two
   approaches are used.  First, each BTC metric must be much more
   tightly specified than the typical IETF transport protocol.  Second,
   each BTC methodology is expected to collect some ancillary metrics
   which are potentially useful to support analytical models of BTC.  If
   a BTC methodology does not collect these ancillary metrics, it should
   collect enough information such that these metrics can be derived
   (for instance a segment trace file).

   As an example, the models in [PFTK98, MSMO97, OKM96a, Lak94] all
   predict bulk transfer performance based on path properties such as
   loss rate and round trip time.  A BTC methodology that also provides
   ancillary measures of these properties is stronger because agreement
   with the analytical models can be used to corroborate the direct BTC
   measurement results.

   More importantly the ancillary metrics are expected to be useful for
   resolving disparity between different BTC methodologies.  For
   example, a path that predominantly experiences clustered packet
   losses is likely to exhibit vastly different measures from BTC
   metrics that mimic Tahoe, Reno, NewReno, and SACK TCP algorithms
   [FF96].  The differences in the BTC metrics over such a path might be
   diagnosed by an ancillary measure of loss clustering.








Mathis, et al.               Informational                      [Page 3]

RFC 3148      Framework for Defining Empirical BTC Metrics     July 2001


   There are some path properties which are best measured as ancillary
   metrics to a transport protocol.  Examples of such properties include
   bottleneck queue limits or the tendency to reorder packets.  These
   are difficult or impossible to measure at low rates and unsafe to
   measure at rates higher than the bulk transport capacity of the path.

   It is expected that at some point in the future there will exist an
   A-frame [RFC2330] which will unify all simple path metrics (e.g.,
   segment loss rates, round trip time) and BTC ancillary metrics (e.g.,
   queue size and packet reordering) with different versions of BTC
   metrics (e.g., that parallel Reno or SACK TCP).

2   Congestion Control Algorithms

   Nearly all TCP implementations in use today utilize the congestion
   control algorithms published in [Jac88] and further refined in
   [RFC2581].  In addition to using the basic notion of using an ACK
   clock, TCP (and therefore BTC) implements five standard congestion
   control algorithms: Congestion Avoidance, Retransmission timeouts,
   Slow-start, Fast Retransmit and Fast Recovery.  All BTC
   implementations MUST implement slow start and congestion avoidance,
   as specified in [RFC2581] (with extra details also specified, as
   outlined below).  All BTC methodologies SHOULD implement fast
   retransmit and fast recovery as outlined in [RFC2581].  Finally, all
   BTC methodologies MUST implement a retransmission timeout.

   The algorithms specified in [RFC2581] give implementers some choices
   in the details of the implementation.  The following is a list of
   details about the congestion control algorithms that are either
   underspecified in [RFC2581] or very important to define when
   constructing a BTC methodology.  These details MUST be specifically
   defined in each BTC methodology.

      *  [RFC2581] does not standardize a specific algorithm for
         increasing cwnd during congestion avoidance.  Several candidate
         algorithms are given in [RFC2581].  The algorithm used in a
         particular BTC methodology MUST be defined.

      *  [RFC2581] does not specify which cwnd increase algorithm (slow
         start or congestion avoidance) should be used when cwnd equals
         ssthresh.  This MUST be specified for each BTC methodology.

      *  [RFC2581] allows TCPs to use advanced loss recovery mechanism
         such as NewReno [RFC2582,FF96,Hoe96] and SACK-based algorithms
         [FF96,MM96a,MM96b].  If used in a BTC implementation, such an
         algorithm MUST be fully defined.





Mathis, et al.               Informational                      [Page 4]

RFC 3148      Framework for Defining Empirical BTC Metrics     July 2001


      *  The actual segment size, or method of choosing a segment size
         (e.g., path MTU discovery [RFC1191]) and the number of header
         bytes assumed to be prepended to each segment MUST be
         specified.  In addition, if the segment size is artificially
         limited to less than the path MTU this MUST be indicated.

      *  TCP includes a retransmission timeout (RTO) to trigger
         retransmissions of segments that have not been acknowledged
         within an appropriate amount of time and have not been
         retransmitted via some more advanced loss recovery algorithm.
         A BTC implementation MUST include a retransmission timer.
         Calculating the RTO is subject to a number of details that MUST
         be defined for each BTC metric.  In addition, a BTC metric MUST
         define when the clock is set and the granularity of the clock.

         [RFC2988] specifies the behavior of the retransmission timer.
         However, there are several details left to the implementer
         which MUST be specified for each BTC metric defined.

   Note that as new congestion control algorithms are placed on the
   standards track they may be incorporated into BTC metrics (e.g., the
   Limited Transmit algorithm [ABF00]).  However, any implementation
   decisions provided by the relevant RFCs SHOULD be fully specified in
   the particular BTC metric.

3   Ancillary Metrics

   The following ancillary metrics can provide additional information
   about the network and the behavior of the implemented congestion
   control algorithms in response to the behavior of the network path.
   It is RECOMMENDED that these metrics be built into each BTC
   methodology.  Alternatively, it is RECOMMENDED that the BTC
   implementation provide enough information such that the ancillary
   metrics can be derived via post-processing (e.g., by providing a
   segment trace of the connection).

3.1 Congestion Avoidance Capacity

   The "Congestion Avoidance Capacity" (CAC) metric is the data rate
   (bits per second) of a fully specified implementation of the
   Congestion Avoidance algorithm, subject to the restriction that the
   Retransmission Timeout and Slow-Start algorithms are not invoked.
   The CAC metric is defined to have no meaning across Retransmission
   Timeouts or Slow-Start periods (except the single segment Slow-Start
   that is permitted to follow recovery, as discussed in section 2).






Mathis, et al.               Informational                      [Page 5]

RFC 3148      Framework for Defining Empirical BTC Metrics     July 2001


   In principle a CAC metric would be an ideal BTC metric, as it
   captures what should be TCP's steady state behavior.  But, there is a
   rather substantial difficulty with using it as such.  The Self-
   Clocking of the Congestion Avoidance algorithm can be very fragile,
   depending on the specific details of the Fast Retransmit, Fast
   Recovery or advanced recovery algorithms chosen.  It has been found
   that timeouts and periods of slow start loss recovery are prevalent
   in traffic on the Internet [LK98,BPS+97] and therefore these should
   be captured by the BTC metric.

   When TCP loses Self-Clock it is re-established through a
   retransmission timeout and Slow-Start.  These algorithms nearly
   always require more time than Congestion Avoidance would have taken.
   It is easily observed that unless the network loses an entire window