A Framework for Defining Empirical Bulk Transfer Capacity Metrics
RFC 3148
|
| Document |
Type |
|
RFC - Informational
(July 2001; No errata)
|
|
Last updated |
|
2013-03-02
|
|
Stream |
|
IETF
|
|
Formats |
|
plain text
pdf
html
bibtex
|
| Stream |
WG state
|
|
(None)
|
|
Document shepherd |
|
No shepherd assigned
|
| IESG |
IESG state |
|
RFC 3148 (Informational)
|
|
Consensus Boilerplate |
|
Unknown
|
|
Telechat date |
|
|
|
Responsible AD |
|
(None)
|
|
Send notices to |
|
(None)
|
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-
Show full document text