RFC 3148 (rfc3148) - Page 2 of 16

A Framework for Defining Empirical Bulk Transfer Capacity Metrics

RFC 3148      Framework for Defining Empirical BTC Metrics     July 2001


   [RFC 2119] 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.

   [RFC 2581] 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