draft-ietf-ippm-btc-framework-05.txt   rfc3148.txt 
INTERNET-DRAFT Expires May 2001 INTERNET-DRAFT
Network Working Group Matt Mathis Network Working Group M. Mathis
INTERNET-DRAFT Pittsburgh Supercomputing Center Request for Comments: 3148 Pittsburgh Supercomputing Center
Expiration Date: May 2001 Mark Allman Category: Informational M. Allman
BBN/NASA Glenn BBN/NASA Glenn
February, 2001 July 2001
A Framework for Defining Empirical Bulk Transfer Capacity Metrics A Framework for Defining Empirical Bulk Transfer Capacity Metrics
< draft-ietf-ippm-btc-framework-05.txt > Status of this Memo
Status of this Document
This document is an Internet-Draft and is in full conformance with This memo provides information for the Internet community. It does
all provisions of Section 10 of RFC2026. not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering Copyright Notice
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Copyright (C) The Internet Society (2001). All Rights Reserved.
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as ``work in
progress.''
The list of current Internet-Drafts can be accessed at Abstract
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document defines a framework for standardizing multiple BTC
http://www.ietf.org/shadow.html. (Bulk Transport Capacity) metrics that parallel the permitted
transport diversity.
Abstract 1 Introduction
Bulk Transport Capacity (BTC) is a measure of a network's ability to Bulk Transport Capacity (BTC) is a measure of a network's ability to
transfer significant quantities of data with a single transfer significant quantities of data with a single congestion-
congestion-aware transport connection (e.g., TCP). The intuitive aware transport connection (e.g., TCP). The intuitive definition of
definition of BTC is the expected long term average data rate (bits BTC is the expected long term average data rate (bits per second) of
per second) of a single ideal TCP implementation over the path in a single ideal TCP implementation over the path in question.
question. However, there are many congestion control algorithms However, there are many congestion control algorithms (and hence
(and hence transport implementations) permitted by IETF standards. transport implementations) permitted by IETF standards. This
This diversity in transport algorithms creates a difficulty for diversity in transport algorithms creates a difficulty for
standardizing BTC metrics because the allowed diversity is standardizing BTC metrics because the allowed diversity is sufficient
sufficient to lead to situations where different implementations to lead to situations where different implementations will yield
will yield non-comparable measures -- and potentially fail the non-comparable measures -- and potentially fail the formal tests for
formal tests for being a metric. being a metric.
This document defines a framework for standardizing multiple BTC Two approaches are used. First, each BTC metric must be much more
metrics that parallel the permitted transport diversity. Two tightly specified than the typical IETF protocol. Second, each BTC
approaches are used. First, each BTC metric must be much more methodology is expected to collect some ancillary metrics which are
tightly specified than the typical IETF protocol. Pseudo-code or potentially useful to support analytical models of BTC.
reference implementations are expected to be the norm. Second, each
BTC methodology is expected to collect some ancillary metrics which
are potentially useful to support analytical models of BTC.
1 Introduction 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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", [RFC2119] was written with protocols in mind, the key words are used
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this in this document for similar reasons. They are used to ensure that
document are to be interpreted as described in [RFC2119]. Although each BTC methodology defined contains specific pieces of information.
[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 Bulk Transport Capacity (BTC) is a measure of a network's ability to
transfer significant quantities of data with a single transfer significant quantities of data with a single congestion-
congestion-aware transport connection (e.g., TCP). For many aware transport connection (e.g., TCP). For many applications the
applications the BTC of the underlying network dominates the overall BTC of the underlying network dominates the overall elapsed time for
elapsed time for the application to run and thus dominates the the application to run and thus dominates the performance as
performance as perceived by a user. Examples of such applications perceived by a user. Examples of such applications include FTP, and
include FTP, and the world wide web when delivering large images or the world wide web when delivering large images or documents. The
documents. The intuitive definition of BTC is the expected long intuitive definition of BTC is the expected long term average data
term average data rate (bits per second) of a single ideal TCP rate (bits per second) of a single ideal TCP implementation over the
implementation over the path in question. The specific definition path in question. The specific definition of the bulk transfer
of the bulk transfer capacity that MUST be reported by a BTC tool is: capacity that MUST be reported by a BTC tool is:
BTC = data_sent / elapsed_time BTC = data_sent / elapsed_time
where ``data_sent'' represents the unique ``data'' bits transfered where "data_sent" represents the unique "data" bits transfered (i.e.,
(i.e., not including header bits or emulated header bits). Also not including header bits or emulated header bits). Also note that
note that the amount of data sent should only include the unique the amount of data sent should only include the unique number of bits
number of bits transmitted (i.e., if a particular packet is transmitted (i.e., if a particular packet is retransmitted the data
retransmitted the data it contains should be counted only once). it contains should be counted only once).
Central to the notion of bulk transport capacity is the idea that Central to the notion of bulk transport capacity is the idea that all
all transport protocols should have similar responses to congestion transport protocols should have similar responses to congestion in
in the Internet. Indeed the only form of equity significantly the Internet. Indeed the only form of equity significantly deployed
deployed in the Internet today is that the vast majority of all in the Internet today is that the vast majority of all traffic is
traffic is carried by TCP implementations sharing common congestion carried by TCP implementations sharing common congestion control
control algorithms largely due to a shared developmental heritage. algorithms largely due to a shared developmental heritage.
[RFC2581] specifies the standard congestion control algorithms used [RFC2581] specifies the standard congestion control algorithms used
by TCP implementations. Even though this document is a (proposed) by TCP implementations. Even though this document is a (proposed)
standard, it permits considerable latitude in implementation. This standard, it permits considerable latitude in implementation. This
latitude is by design, to encourage ongoing evolution in congestion latitude is by design, to encourage ongoing evolution in congestion
control algorithms. control algorithms.
This legal diversity in congestion control algorithms creates a This legal diversity in congestion control algorithms creates a
difficulty for standardizing BTC metrics because the allowed difficulty for standardizing BTC metrics because the allowed
diversity is sufficient to lead to situations where different diversity is sufficient to lead to situations where different
implementations will yield non-comparable measures -- and implementations will yield non-comparable measures -- and potentially
potentially fail the formal tests for being a metric. fail the formal tests for being a metric.
There is also evidence that most TCP implementations exhibit There is also evidence that most TCP implementations exhibit non-
non-linear performance over some portion of their operating region. linear performance over some portion of their operating region. It
It is possible to construct simple simulation examples where is possible to construct simple simulation examples where incremental
incremental improvements to a path (such as raising the link data improvements to a path (such as raising the link data rate) results
rate) results in lower overall TCP throughput (or BTC) [Mat98]. in lower overall TCP throughput (or BTC) [Mat98].
We believe that such non-linearity reflects weakness in our current We believe that such non-linearity reflects weakness in our current
understanding of congestion control and is present to some extent in understanding of congestion control and is present to some extent in
all TCP implementations and BTC metrics. Note that such all TCP implementations and BTC metrics. Note that such non-
non-linearity (in either TCP or a BTC metric) is potentially linearity (in either TCP or a BTC metric) is potentially problematic
problematic in the market because investment in capacity might in the market because investment in capacity might actually reduce
actually reduce the perceived quality of the network. Ongoing the perceived quality of the network. Ongoing research in congestion
research in congestion dynamics has some hope of mitigating or dynamics has some hope of mitigating or modeling the these non-
modeling the these non-linearities. linearities.
Related areas, including integrated services Related areas, including integrated services [RFC1633,RFC2216],
[RFC1633,RFC2216], differentiated services [RFC2475] and Internet differentiated services [RFC2475] and Internet traffic analysis
traffic analysis [MSMO97,PFTK98,Pax97b,LM97] are all currently [MSMO97,PFTK98,Pax97b,LM97] are all currently receiving significant
receiving significant attention from the research community. It is attention from the research community. It is likely that we will see
likely that we will see new experimental congestion control new experimental congestion control algorithms in the near future.
algorithms in the near future. In addition, Explicit Congestion In addition, Explicit Congestion Notification (ECN) [RFC2481] is
Notification (ECN) [RFC2481] is being tested for Internet being tested for Internet deployment. We do not yet know how any of
deployment. We do not yet know how any of these developments might these developments might affect BTC metrics, and thus the BTC
affect BTC metrics, and thus the BTC framework and metrics may need framework and metrics may need to be revisited in the future.
to be revisited in the future.
This document defines a framework for standardizing multiple BTC This document defines a framework for standardizing multiple BTC
metrics that parallel the permitted transport diversity. Two metrics that parallel the permitted transport diversity. Two
approaches are used. First, each BTC metric must be much more approaches are used. First, each BTC metric must be much more
tightly specified than the typical IETF transport protocol. tightly specified than the typical IETF transport protocol. Second,
Pseudo-code or reference implementations are expected to be the each BTC methodology is expected to collect some ancillary metrics
norm. Second, each BTC methodology is expected to collect some which are potentially useful to support analytical models of BTC. If
ancillary metrics which are potentially useful to support analytical a BTC methodology does not collect these ancillary metrics, it should
models of BTC. If a BTC methodology does not collect these collect enough information such that these metrics can be derived
ancillary metrics, it should collect enough information such that (for instance a segment trace file).
these metrics can be derived (for instance a segment trace file).
As an example, the models in [PFTK98, MSMO97, OKM96a, Lak94] all As an example, the models in [PFTK98, MSMO97, OKM96a, Lak94] all
predict bulk transfer performance based on path properties such as predict bulk transfer performance based on path properties such as
loss rate and round trip time. A BTC methodology that also provides loss rate and round trip time. A BTC methodology that also provides
ancillary measures of these properties is stronger because agreement ancillary measures of these properties is stronger because agreement
with the analytical models can be used to corroborate the direct BTC with the analytical models can be used to corroborate the direct BTC
measurement results. measurement results.
More importantly the ancillary metrics are expected to be useful for More importantly the ancillary metrics are expected to be useful for
resolving disparity between different BTC methodologies. For resolving disparity between different BTC methodologies. For
example, a path that predominantly experiences clustered packet example, a path that predominantly experiences clustered packet
losses is likely to exhibit vastly different measures from BTC losses is likely to exhibit vastly different measures from BTC
metrics that mimic Tahoe, Reno, NewReno, and SACK TCP algorithms metrics that mimic Tahoe, Reno, NewReno, and SACK TCP algorithms
[FF96]. The differences in the BTC metrics over such a path might [FF96]. The differences in the BTC metrics over such a path might be
be diagnosed by an ancillary measure of loss clustering. diagnosed by an ancillary measure of loss clustering.
There are some path properties which are best measured as ancillary There are some path properties which are best measured as ancillary
metrics to a transport protocol. Examples of such properties metrics to a transport protocol. Examples of such properties include
include bottleneck queue limits or the tendency to reorder packets. bottleneck queue limits or the tendency to reorder packets. These
These are difficult or impossible to measure at low rates and unsafe are difficult or impossible to measure at low rates and unsafe to
to measure at rates higher than the bulk transport capacity of the measure at rates higher than the bulk transport capacity of the path.
path.
It is expected that at some point in the future there will exist an 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., A-frame [RFC2330] which will unify all simple path metrics (e.g.,
segment loss rates, round trip time) and BTC ancillary metrics segment loss rates, round trip time) and BTC ancillary metrics (e.g.,
(e.g., queue size and packet reordering) with different versions of queue size and packet reordering) with different versions of BTC
BTC metrics (e.g., that parallel Reno or SACK TCP). metrics (e.g., that parallel Reno or SACK TCP).
2 Congestion Control Algorithms 2 Congestion Control Algorithms
Nearly all TCP implementations in use today utilize the congestion Nearly all TCP implementations in use today utilize the congestion
control algorithms published in [Jac88] and further refined in control algorithms published in [Jac88] and further refined in
[RFC2581]. In addition to using the basic notion of using an ACK [RFC2581]. In addition to using the basic notion of using an ACK
clock, TCP (and therefore BTC) implements five standard congestion clock, TCP (and therefore BTC) implements five standard congestion
control algorithms: Congestion Avoidance, Retransmission timeouts, control algorithms: Congestion Avoidance, Retransmission timeouts,
Slow-start, Fast Retransmit and Fast Recovery. All BTC Slow-start, Fast Retransmit and Fast Recovery. All BTC
implementations MUST implement slow start and congestion avoidance, implementations MUST implement slow start and congestion avoidance,
as specified in [RFC2581] (with extra details also specified, as as specified in [RFC2581] (with extra details also specified, as
outlined below). All BTC methodologies SHOULD implement fast outlined below). All BTC methodologies SHOULD implement fast
retransmit and fast recovery as outlined in [RFC2581]. Finally, all retransmit and fast recovery as outlined in [RFC2581]. Finally, all
BTC methodologies MUST implement a retransmission timeout. BTC methodologies MUST implement a retransmission timeout.
The algorithms specified in [RFC2581] give implementers some choices The algorithms specified in [RFC2581] give implementers some choices
in the details of the implementation. The following is a list of in the details of the implementation. The following is a list of
details about the congestion control algorithms that are either details about the congestion control algorithms that are either
underspecified in [RFC2581] or very important to define when underspecified in [RFC2581] or very important to define when
constructing a BTC methodology. These details MUST be specifically constructing a BTC methodology. These details MUST be specifically
defined in each BTC methodology. defined in each BTC methodology.
* [RFC2581] does not standardize a specific algorithm for * [RFC2581] does not standardize a specific algorithm for
increasing cwnd during congestion avoidance. Several candidate increasing cwnd during congestion avoidance. Several candidate
algorithms are given in [RFC2581]. The algorithm used in a algorithms are given in [RFC2581]. The algorithm used in a
particular BTC methodology MUST be defined. particular BTC methodology MUST be defined.
* [RFC2581] does not specify which cwnd increase algorithm (slow * [RFC2581] does not specify which cwnd increase algorithm (slow
start or congestion avoidance) should be used when cwnd equals start or congestion avoidance) should be used when cwnd equals
ssthresh. This MUST be specified for each BTC methodology. ssthresh. This MUST be specified for each BTC methodology.
* [RFC2581] allows TCPs to use advanced loss recovery mechanism * [RFC2581] allows TCPs to use advanced loss recovery mechanism
such as NewReno [RFC2582,FF96,Hoe96] and SACK-based algorithms such as NewReno [RFC2582,FF96,Hoe96] and SACK-based algorithms
[FF96,MM96a,MM96b]. If used in a BTC implementation, such an [FF96,MM96a,MM96b]. If used in a BTC implementation, such an
algorithm MUST be fully defined. algorithm MUST be fully defined.
* The actual segment size, or method of choosing a segment size * The actual segment size, or method of choosing a segment size
(e.g., path MTU discovery [RFC1191]) and the number of header (e.g., path MTU discovery [RFC1191]) and the number of header
bytes assumed to be prepended to each segment MUST be specified. bytes assumed to be prepended to each segment MUST be
In addition, if the segment size is artificially limited to less specified. In addition, if the segment size is artificially
than the path MTU this MUST be indicated. limited to less than the path MTU this MUST be indicated.
* TCP includes a retransmission timeout (RTO) to trigger * TCP includes a retransmission timeout (RTO) to trigger
retransmissions of segments that have not been acknowledged retransmissions of segments that have not been acknowledged
within an appropriate amount of time and have not been within an appropriate amount of time and have not been
retransmitted via some more advanced loss recovery algorithm. A retransmitted via some more advanced loss recovery algorithm.
BTC implementation MUST include a retransmission timer. A BTC implementation MUST include a retransmission timer.
Calculating the RTO is subject to a number of details that MUST Calculating the RTO is subject to a number of details that MUST
be defined for each BTC metric. In addition, a BTC metric 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. define when the clock is set and the granularity of the clock.
[RFC2988] specifies the behavior of the retransmission timer. [RFC2988] specifies the behavior of the retransmission timer.
However, there are several details left to the implementer which However, there are several details left to the implementer
MUST be specified for each BTC metric defined. which MUST be specified for each BTC metric defined.
Note that as new congestion control algorithms are placed on the Note that as new congestion control algorithms are placed on the
standards track they may be incorporated into BTC metrics (e.g., the standards track they may be incorporated into BTC metrics (e.g., the
Limited Transmit algorithm [ABF00]). However, any implementation Limited Transmit algorithm [ABF00]). However, any implementation
decisions provided by the relevant RFCs SHOULD be fully specified in decisions provided by the relevant RFCs SHOULD be fully specified in
the particular BTC metric. the particular BTC metric.
3 Ancillary Metrics 3 Ancillary Metrics
The following ancillary metrics can provide additional information The following ancillary metrics can provide additional information
about the network and the behavior of the implemented congestion about the network and the behavior of the implemented congestion
control algorithms in response to the behavior of the network path. control algorithms in response to the behavior of the network path.
It is RECOMMENDED that these metrics be built into each BTC It is RECOMMENDED that these metrics be built into each BTC
methodology. Alternatively, it is RECOMMENDED that the BTC methodology. Alternatively, it is RECOMMENDED that the BTC
implementation provide enough information such that the ancillary implementation provide enough information such that the ancillary
metrics can be derived via post-processing (e.g., by providing a metrics can be derived via post-processing (e.g., by providing a
segment trace of the connection). segment trace of the connection).
3.1 Congestion Avoidance Capacity 3.1 Congestion Avoidance Capacity
The "Congestion Avoidance Capacity" (CAC) metric is the data rate The "Congestion Avoidance Capacity" (CAC) metric is the data rate
(bits per second) of a fully specified implementation of the (bits per second) of a fully specified implementation of the
Congestion Avoidance algorithm, subject to the restriction that the Congestion Avoidance algorithm, subject to the restriction that the
Retransmission Timeout and Slow-Start algorithms are not invoked. Retransmission Timeout and Slow-Start algorithms are not invoked.
The CAC metric is defined to have no meaning across Retransmission The CAC metric is defined to have no meaning across Retransmission
Timeouts or Slow-Start periods (except the single segment Slow-Start Timeouts or Slow-Start periods (except the single segment Slow-Start
that is permitted to follow recovery, as discussed in section 2). that is permitted to follow recovery, as discussed in section 2).
In principle a CAC metric would be an ideal BTC metric, as it 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 captures what should be TCP's steady state behavior. But, there is a
a rather substantial difficulty with using it as such. The rather substantial difficulty with using it as such. The Self-
Self-Clocking of the Congestion Avoidance algorithm can be very Clocking of the Congestion Avoidance algorithm can be very fragile,
fragile, depending on the specific details of the Fast Retransmit, depending on the specific details of the Fast Retransmit, Fast
Fast Recovery or advanced recovery algorithms chosen. It has been Recovery or advanced recovery algorithms chosen. It has been found
found that timeouts and periods of slow start loss recovery are that timeouts and periods of slow start loss recovery are prevalent
prevalent in traffic on the Internet [LK98,BPS+97] and therefore these in traffic on the Internet [LK98,BPS+97] and therefore these should
should be captured by the BTC metric. be captured by the BTC metric.
When TCP loses Self-Clock it is re-established through a When TCP loses Self-Clock it is re-established through a
retransmission timeout and Slow-Start. These algorithms nearly retransmission timeout and Slow-Start. These algorithms nearly
always require more time than Congestion Avoidance would have taken. always require more time than Congestion Avoidance would have taken.
It is easily observed that unless the network loses an entire window It is easily observed that unless the network loses an entire window
of data (which would clearly require a retransmit timeout) TCP of data (which would clearly require a retransmit timeout) TCP likely
likely missed some opportunity to safely transmit data. That is, if TCP missed some opportunity to safely transmit data. That is, if TCP
experiences a timeout after losing a partial window of data, it must experiences a timeout after losing a partial window of data, it must
have received at least one ACK that was generated after some of the have received at least one ACK that was generated after some of the
partial data was delivered, but did not trigger the transmission of partial data was delivered, but did not trigger the transmission of
new data. Recent research in congestion control (e.g., FACK new data. Recent research in congestion control (e.g., FACK [MM96a],
[MM96a], NewReno [FF96,RFC2582], rate-halving [MSML99]) can be NewReno [FF96,RFC2582], rate-halving [MSML99]) can be characterized
characterized as making TCP's Self-Clock more tenacious, while as making TCP's Self-Clock more tenacious, while preserving fairness
preserving fairness under adverse conditions. This work is under adverse conditions. This work is motivated by how poorly
motivated by how poorly current TCP implementations perform under current TCP implementations perform under some conditions, often due
some conditions, often due to repeated clock loss. Since this is an to repeated clock loss. Since this is an active research area,
active research area, different TCP implementations have rather different TCP implementations have rather considerable differences in
considerable differences in their ability to preserve Self-Clock. their ability to preserve Self-Clock.
3.2 Preservation of Self-Clock 3.2 Preservation of Self-Clock
Losing the ACK clock can have a large effect on the overall BTC, and Losing the ACK clock can have a large effect on the overall BTC, and
the clock is itself fragile in ways that are dependent on the loss the clock is itself fragile in ways that are dependent on the loss
recovery algorithm. Therefore, the transition between timer driven recovery algorithm. Therefore, the transition between timer driven
and Self-Clocked operation SHOULD be instrumented. and Self-Clocked operation SHOULD be instrumented.
3.2.1 Lost Transmission Opportunities 3.2.1 Lost Transmission Opportunities
If the last event before a timeout was the receipt of an ACK that If the last event before a timeout was the receipt of an ACK that did
did not trigger a transmission, the possibility exists that an not trigger a transmission, the possibility exists that an alternate
alternate congestion control algorithm would have successfully congestion control algorithm would have successfully preserved the
preserved the Self-Clock. A BTC SHOULD instrument key items in the Self-Clock. A BTC SHOULD instrument key items in the BTC state (such
BTC state (such as the congestion window) in the hopes that this may as the congestion window) in the hopes that this may lead to further
lead to further improvements in congestion control algorithms. improvements in congestion control algorithms.
Note that in the absence of knowledge about the future, it is not Note that in the absence of knowledge about the future, it is not
possible to design an algorithm that never misses transmission possible to design an algorithm that never misses transmission
opportunities. However, there are ever more subtle ways to gauge opportunities. However, there are ever more subtle ways to gauge
network state, and to estimate if a given ACK is likely to be the network state, and to estimate if a given ACK is likely to be the
last. last.
3.2.2 Loosing an Entire Window 3.2.2 Loosing an Entire Window
If an entire window of data (or ACKs) is lost, there will be no If an entire window of data (or ACKs) is lost, there will be no
returning ACKs to clock out additional data. This condition can returning ACKs to clock out additional data. This condition can be
be detected if the last event before a timeout was a data detected if the last event before a timeout was a data transmission
transmission triggered by an ACK. The loss of an entire window triggered by an ACK. The loss of an entire window of data/ACKs
of data/ACKs forces recovery to be via a Retransmission Timeout and forces recovery to be via a Retransmission Timeout and Slow-Start.
Slow-Start.
Losing an entire window of data implies an outage with a duration at Losing an entire window of data implies an outage with a duration at
least as long as a round trip time. Such an outage can not be least as long as a round trip time. Such an outage can not be
diagnosed with low rate metrics and is unsafe to diagnose at higher diagnosed with low rate metrics and is unsafe to diagnose at higher
rates than the BTC. Therefore all BTC metrics SHOULD instrument and rates than the BTC. Therefore all BTC metrics SHOULD instrument and
report losses of an entire window of data. report losses of an entire window of data.
Note that there are some conditions, such as when operating with a Note that there are some conditions, such as when operating with a
very small window, in which there is a significant probability that very small window, in which there is a significant probability that
an entire window can be lost through individual random losses (again an entire window can be lost through individual random losses (again
highlighting the importance of instrumenting cwnd). highlighting the importance of instrumenting cwnd).
3.2.3 Heroic Clock Preservation 3.2.3 Heroic Clock Preservation
All algorithms that permit a given BTC to sustain Self-Clock when All algorithms that permit a given BTC to sustain Self-Clock when
other algorithms might not, SHOULD be instrumented. Furthermore, other algorithms might not, SHOULD be instrumented. Furthermore, the
the details of the algorithms used MUST be fully documented (as details of the algorithms used MUST be fully documented (as discussed
discussed in section 2). in section 2).
BTC metrics that can sustain Self-Clock in the presence of multiple BTC metrics that can sustain Self-Clock in the presence of multiple
losses within one round trip SHOULD instrument the loss losses within one round trip SHOULD instrument the loss distribution,
distribution, such that the performance of alternate congestion such that the performance of alternate congestion control algorithms
control algorithms may be estimated (e.g., Reno style). may be estimated (e.g., Reno style).
3.2.4 False Timeouts 3.2.4 False Timeouts
All false timeouts, (where the retransmission timer expires before All false timeouts, (where the retransmission timer expires before
the ACK for some previously transmitted data arrives) SHOULD be the ACK for some previously transmitted data arrives) SHOULD be
instrumented when possible. Note that depending upon how the BTC instrumented when possible. Note that depending upon how the BTC
metric implements sequence numbers, this may be difficult to detect. metric implements sequence numbers, this may be difficult to detect.
3.3 Ancillary Metrics Relating to Flow Based Path Properties 3.3 Ancillary Metrics Relating to Flow Based Path Properties
All BTC metrics provide unique vantage points for observing certain All BTC metrics provide unique vantage points for observing certain
path properties relating to closely spaced packets. As in the case path properties relating to closely spaced packets. As in the case
of RTT duration outages, these can be impossible to diagnose at low of RTT duration outages, these can be impossible to diagnose at low
rates (less than 1 packet per RTT) and inappropriate to test at rates (less than 1 packet per RTT) and inappropriate to test at rates
rates above the BTC of the network path. above the BTC of the network path.
All BTC metrics SHOULD instrument packet reordering. The frequency All BTC metrics SHOULD instrument packet reordering. The frequency
and distance out-of-sequence SHOULD be instrumented for all and distance out-of-sequence SHOULD be instrumented for all out-of-
out-of-order packets. The severity of the reordering can be order packets. The severity of the reordering can be classified as
classified as one of three different cases, each of which SHOULD be one of three different cases, each of which SHOULD be reported.
reported.
Segments that are only slightly out-of-order should not trigger Segments that are only slightly out-of-order should not trigger
the fast retransmit algorithm, but they may affect the window the fast retransmit algorithm, but they may affect the window
calculation. BTC metrics SHOULD document how slightly calculation. BTC metrics SHOULD document how slightly out-of-
out-of-order segments affect the congestion window calculation. order segments affect the congestion window calculation.
If segments are sufficiently out-of-order, the Fast Retransmit If segments are sufficiently out-of-order, the Fast Retransmit
algorithm will be invoked in advance of the delayed packet's algorithm will be invoked in advance of the delayed packet's late
late arrival. These events SHOULD be instrumented. Even though arrival. These events SHOULD be instrumented. Even though the
the the late arriving packet will complete recovery, the the the late arriving packet will complete recovery, the the window
window will still be reduced by half. will still be reduced by half.
Under some rare conditions segments have been observed that are Under some rare conditions segments have been observed that are
far out of order - sometimes many seconds late [Pax97b]. These far out of order - sometimes many seconds late [Pax97b]. These
SHOULD always be instrumented. SHOULD always be instrumented.
BTC implementations SHOULD instrument the maximum cwnd observed BTC implementations SHOULD instrument the maximum cwnd observed
during congestion avoidance and slow start. A TCP running over the during congestion avoidance and slow start. A TCP running over the
same path as the BTC metric must have sufficient sender buffer space same path as the BTC metric must have sufficient sender buffer space
and receiver window (and window shift [RFC1323]) to cover this cwnd and receiver window (and window shift [RFC1323]) to cover this cwnd
in order to expect the same performance. in order to expect the same performance.
There are several other path properties that one might measure There are several other path properties that one might measure within
within a BTC metric. For example, with an embedded one-way delay a BTC metric. For example, with an embedded one-way delay metric it
metric it may be possible to measure how queueing delay and and may be possible to measure how queuing delay and and (RED) drop
(RED) drop probabilities are correlated to window size. These are probabilities are correlated to window size. These are open research
open research questions. questions.
3.4 Ancillary Metrics as Calibration Checks 3.4 Ancillary Metrics as Calibration Checks
Unlike low rate metrics, BTC SHOULD include explicit checks that the Unlike low rate metrics, BTC SHOULD include explicit checks that the
test platform is not the bottleneck. test platform is not the bottleneck.
Any detected dropped packets within the sending host MUST be reported. Any detected dropped packets within the sending host MUST be
Unless the sending interface is the path bottleneck, any dropped reported. Unless the sending interface is the path bottleneck, any
packets probably indicates a measurement failure. dropped packets probably indicates a measurement failure.
The maximum queue lengths within the sending host SHOULD be The maximum queue lengths within the sending host SHOULD be
instrumented. Any significant queue may indicate that the sending instrumented. Any significant queue may indicate that the sending
host has insufficient burst data rate, and is smoothing the data host has insufficient burst data rate, and is smoothing the data
being transmitted into the network. being transmitted into the network.
3.5 Ancillary Metrics Relating to the Need for Advanced TCP Features 3.5 Ancillary Metrics Relating to the Need for Advanced TCP Features
If TCP would require advanced TCP extensions to match BTC If TCP would require advanced TCP extensions to match BTC performance
performance (such as RFC 1323 or RFC 2018 features), it SHOULD be (such as RFC 1323 or RFC 2018 features), it SHOULD be reported.
reported.
3.6 Validate Reverse Path Load 3.6 Validate Reverse Path Load
To the extent possible, the BTC metric SHOULD distinguish between To the extent possible, the BTC metric SHOULD distinguish between the
the properties of the forward and reverse paths. properties of the forward and reverse paths.
BTC methodologies which rely on non-cooperating receivers may only BTC methodologies which rely on non-cooperating receivers may only be
be able to measure round trip path properties and may not be able to able to measure round trip path properties and may not be able to
independently differentiate between the properties of the forward independently differentiate between the properties of the forward and
and reverse paths. In this case the load on the reverse path reverse paths. In this case the load on the reverse path contributed
contributed by the BTC metric SHOULD be instrumented (or computed) by the BTC metric SHOULD be instrumented (or computed) to permit
to permit other means of gauge the proportion of the round trip path other means of gauge the proportion of the round trip path properties
properties attributed to the the forward and reverse paths. attributed to the the forward and reverse paths.
To the extent possible, BTC methodologies that rely on cooperating To the extent possible, BTC methodologies that rely on cooperating
receivers SHOULD support separate ancillary metrics for the forward receivers SHOULD support separate ancillary metrics for the forward
and reverse paths. and reverse paths.
4 Security Considerations 4 Security Considerations
Conducting Internet measurements raises security concerns. This Conducting Internet measurements raises security concerns. This memo
memo does not specify a particular implementation of a metric, so it does not specify a particular implementation of a metric, so it does
does not directly affect the security of the Internet nor of not directly affect the security of the Internet nor of applications
applications which run on the Internet. However, metrics produced which run on the Internet. However, metrics produced within this
within this framework, and in particular implementations of the framework, and in particular implementations of the metrics may
metrics may create security issues. create security issues.
4.1 Denial of Service Attacks 4.1 Denial of Service Attacks
Bulk Transport Capacity metrics, as defined in this document, Bulk Transport Capacity metrics, as defined in this document,
naturally attempt to fill a bottleneck link. The BTC metrics based naturally attempt to fill a bottleneck link. The BTC metrics based
on this specification will be as ``network friendly'' as current on this specification will be as "network friendly" as current well-
well-tuned TCP connections. However, since the ``connection'' may tuned TCP connections. However, since the "connection" may not be
not be using TCP packets, a BTC test may appear to network operators using TCP packets, a BTC test may appear to network operators as a
as a denial of service attack. denial of service attack.
Administrators of the source host of a test, the destination host of Administrators of the source host of a test, the destination host of
a test, and the intervening network(s) may wish to establish a test, and the intervening network(s) may wish to establish
bilateral or multi-lateral agreements regarding the timing, size, bilateral or multi-lateral agreements regarding the timing, size, and
and frequency of collection of BTC metrics. frequency of collection of BTC metrics.
4.2 User data confidentiality 4.2 User data confidentiality
Metrics within this framework generate packets for a sample, rather Metrics within this framework generate packets for a sample, rather
than taking samples based on user data. Thus, a BTC metric does not than taking samples based on user data. Thus, a BTC metric does not
threaten user data confidentiality. threaten user data confidentiality.
4.3 Interference with metrics 4.3 Interference with metrics
It may be possible to identify that a certain packet or stream of It may be possible to identify that a certain packet or stream of
packets are part of a BTC metric. With that knowledge at the packets are part of a BTC metric. With that knowledge at the
destination and/or the intervening networks, it is possible to destination and/or the intervening networks, it is possible to change
change the processing of the packets (e.g. increasing or decreasing the processing of the packets (e.g., increasing or decreasing delay,
delay, introducing or heroically preventing loss) that may distort introducing or heroically preventing loss) that may distort the
the measured performance. It may also be possible to generate measured performance. It may also be possible to generate additional
additional packets that appear to be part of a BTC metric. These packets that appear to be part of a BTC metric. These additional
additional packets are likely to perturb the results of the sample packets are likely to perturb the results of the sample measurement.
measurement.
To discourage the kind of interference mentioned above, packet To discourage the kind of interference mentioned above, packet
interference checks, such as cryptographic hash, may be used. interference checks, such as cryptographic hash, may be used.
5 IANA Considerations 5 IANA Considerations
Since this metric framework does not define a specific Since this metric framework does not define a specific protocol, nor
protocol, nor does it define any well-known values, there does it define any well-known values, there are no IANA
are no IANA considerations for this document. However, considerations for this document. However, a bulk transport capacity
a bulk transport capacity metric within this framework, metric within this framework, and in particular protocols that
and in particular protocols that implement a metric may have implement a metric may have IANA considerations that need to be
IANA considerations that need to be addressed. addressed.
6 Acknowledgments 6 Acknowledgments
Thanks to Wil Leland, Jeff Semke, Matt Zekauskas and the IPPM Thanks to Wil Leland, Jeff Semke, Matt Zekauskas and the IPPM working
working group for numerous clarifications. group for numerous clarifications.
Matt Mathis's work was supported by the National Science Foundation
under Grant Numbers 9415552 and 9870758.
7 References 7 References
[BPS+97] Hari Balakrishnan, Venkata Padmanabhan, Srinivasan Seshan, [BPS+97] Hari Balakrishnan, Venkata Padmanabhan, Srinivasan
Mark Stemm, and Randy Katz. TCP Behavior of a Busy Web Server: Seshan, Mark Stemm, and Randy Katz. TCP Behavior of a
Analysis and Improvements. Technical Report UCB/CSD-97-966, Busy Web Server: Analysis and Improvements. Technical
August 1997. Available from Report UCB/CSD-97-966, August 1997. Available from
http://nms.lcs.mit.edu/~hari/papers/csd-97-966.ps. (Also in http://nms.lcs.mit.edu/~hari/papers/csd-97-966.ps.
Proc. IEEE INFOCOM Conf., San Francisco, CA, March 1998.) (Also in Proc. IEEE INFOCOM Conf., San Francisco, CA,
March 1998.)
[FF96] Fall, K., Floyd, S.. "Simulation-based Comparisons of Tahoe, [FF96] Fall, K., Floyd, S.. "Simulation-based Comparisons of
Reno and SACK TCP". Computer Communication Review, July 1996. Tahoe, Reno and SACK TCP". Computer Communication
ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z. Review, July 1996.
ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z.
[Flo95] Floyd, S., "TCP and successive fast retransmits", March [Flo95] Floyd, S., "TCP and successive fast retransmits", March
1995, Obtain via ftp://ftp.ee.lbl.gov/papers/fastretrans.ps. 1995, Obtain via
ftp://ftp.ee.lbl.gov/papers/fastretrans.ps.
[Hoe96] Hoe, J., "Improving the start-up behavior of a congestion [Hoe96] Hoe, J., "Improving the start-up behavior of a
control scheme for TCP, Proceedings of ACM SIGCOMM '96, August congestion control scheme for TCP, Proceedings of ACM
1996. SIGCOMM '96, August 1996.
[Hoe95] Hoe, J., "Startup dynamics of TCP's congestion control and [Hoe95] Hoe, J., "Startup dynamics of TCP's congestion control
avoidance schemes". Master's thesis, Massachusetts Institute of and avoidance schemes". Master's thesis, Massachusetts
Technology, June 1995. Institute of Technology, June 1995.
[Jac88] Jacobson, V., "Congestion Avoidance and Control", [Jac88] Jacobson, V., "Congestion Avoidance and Control",
Proceedings of SIGCOMM '88, Stanford, CA., August 1988. Proceedings of SIGCOMM '88, Stanford, CA., August 1988.
[Lak94] Lakshman, Effects of random loss [Lak94] V. T. Lakshman and U. Madhow. The Performance of TCP/IP
for Networks with High Bandwidth-Delay Products and
Random Loss. IFIP Transactions C-26, High Performance
Networking, pages 135--150, 1994.
[LK98] Lin, D. and Kung, H.T., "TCP Fast Recovery Strategies: [LK98] Lin, D. and Kung, H.T., "TCP Fast Recovery Strategies:
Analysis and Improvements", Proceedings of InfoCom, March 1998. Analysis and Improvements", Proceedings of InfoCom,
March 1998.
[LM97] T.V.Lakshman and U.Madhow. "The Performance of TCP/IP for [LM97] T.V.Lakshman and U.Madhow. "The Performance of TCP/IP
Networks with High Bandwidth-Delay Products and Random Loss". for Networks with High Bandwidth-Delay Products and
IEEE/ACM Transactions on Networking, Vol. 5, No. 3, June 1997, Random Loss". IEEE/ACM Transactions on Networking, Vol.
pp.336-350. 5, No. 3, June 1997, pp.336-350.
[Mat98] Mathis, M., "Empirical Bulk Transfer Capacity", IP [Mat98] Mathis, M., "Empirical Bulk Transfer Capacity", IP
Performance Metrics Working Group report in Proceedings of the Performance Metrics Working Group report in Proceedings
Forty Third Internet Engineering Task Force, Orlando, FL, of the Forty Third Internet Engineering Task Force,
December 1988. Available from Orlando, FL, December 1988. Available from
http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-122.html http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-
and 122.html and
http://www.ietf.org/proceedings/98dec/slides/ippm-mathis-98dec.pdf. http://www.ietf.org/proceedings/98dec/slides/ippm-
mathis-98dec.pdf.
[MM96a] Mathis, M. and Mahdavi, J. "Forward acknowledgment: Refining [MM96a] Mathis, M. and Mahdavi, J. "Forward acknowledgment:
TCP congestion control", Proceedings of ACM SIGCOMM '96, Refining TCP congestion control", Proceedings of ACM
Stanford, CA., August 1996. SIGCOMM '96, Stanford, CA., August 1996.
[MM96b] M. Mathis, J. Mahdavi, "TCP Rate-Halving with Bounding [MM96b] M. Mathis, J. Mahdavi, "TCP Rate-Halving with Bounding
Parameters" Available from Parameters". Available from
http://www.psc.edu/networking/papers/FACKnotes/current. http://www.psc.edu/networking/papers/FACKnotes/current.
[MSML99] Mathis, M., Semke, J., Mahdavi, J., Lahey, K., "The [MSML99] Mathis, M., Semke, J., Mahdavi, J., Lahey, K., "The
Rate-Halving Algorithm for TCP Congestion Control", June 1999. Rate-Halving Algorithm for TCP Congestion Control", June
Internet-Draft draft-mathis-tcp-ratehalving-00.txt (work in 1999, Work in Progress.
progress).
[MSMO97] Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The [MSMO97] Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The
Macroscopic Behavior of the TCP Congestion Avoidance Algorithm", Macroscopic Behavior of the TCP Congestion Avoidance
Computer Communications Review, 27(3), July 1997. Algorithm", Computer Communications Review, 27(3), July
1997.
[OKM96a], Ott, T., Kemperman, J., Mathis, M., "The Stationary [OKM96a], Ott, T., Kemperman, J., Mathis, M., "The Stationary
Behavior of Ideal TCP Congestion Avoidance", In progress, August Behavior of Ideal TCP Congestion Avoidance", In
1996. Obtain via pub/tjo/TCPwindow.ps using anonymous ftp to progress, August 1996. Obtain via pub/tjo/TCPwindow.ps
ftp.bellcore.com using anonymous ftp to ftp.bellcore.com
[OKM96b], Ott, T., Kemperman, J., Mathis, M., "Window Size Behavior [OKM96b], Ott, T., Kemperman, J., Mathis, M., "Window Size
in TCP/IP with Constant Loss Probability", DIMACS Special Year Behavior in TCP/IP with Constant Loss Probability",
on Networks, Workshop on Performance of Real-Time Applications DIMACS Special Year on Networks, Workshop on Performance
on the Internet, Nov 1996. of Real-Time Applications on the Internet, Nov 1996.
[Pax97a] Paxson, V., "Automated Packet Trace Analysis of TCP [Pax97a] Paxson, V., "Automated Packet Trace Analysis of TCP
Implementations", Proceedings of ACM SIGCOMM '97, August 1997. Implementations", Proceedings of ACM SIGCOMM '97, August
1997.
[Pax97b] Paxson, V., "End-to-End Internet Packet Dynamics," [Pax97b] Paxson, V., "End-to-End Internet Packet Dynamics,"
Proceedings of SIGCOMM '97, Cannes, France, Sep. 1997. Proceedings of SIGCOMM '97, Cannes, France, Sep. 1997.
[PFTK98] Padhye, J., Firoiu. V., Towsley, D., and Kurose, J., "TCP [PFTK98] Padhye, J., Firoiu. V., Towsley, D., and Kurose, J.,
Throughput: A Simple Model and its Empirical Validation", "TCP Throughput: A Simple Model and its Empirical
Proceedings of ACM SIGCOMM '98, August 1998. Validation", Proceedings of ACM SIGCOMM '98, August
1998.
[RFC793] Postel, J., "Transmission Control Protocol", 1981, Obtain [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC
via: http://www.rfc-editor.org/rfc/rfc793.txt 793, September 1981. Obtain via: http://www.rfc-
editor.org/rfc/rfc793.txt
[RFC1191] Mogul, J., Deering, S., "Path MTU Discovery", November [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC
1990, Obtain via: http://www.rfc-editor.org/rfc/rfc1191.txt 1191, November 1990. Obtain via: http://www.rfc-
editor.org/rfc/rfc1191.txt
[RFC1323] Jacobson, V., Braden, R., Borman, D., "TCP Extensions for [RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions
High Performance", May 1992, Obtain via: for High Performance", May 1992. Obtain via:
http://www.rfc-editor.org/rfc/rfc1323.txt http://www.rfc-editor.org/rfc/rfc1323.txt
[RFC1633] Braden R., Clark D., Shenker S., "Integrated Services in [RFC1633] Braden R., Clark D. and S. Shenker, "Integrated Services
the Internet Architecture: an Overview", 1994, Obtain via: in the Internet Architecture: an Overview", RFC 1633,
http://www.rfc-editor.org/rfc/rfc1633.txt June 1994. Obtain via: http://www.rfc-
editor.org/rfc/rfc1633.txt
[RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast [RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast
Retransmit, and Fast Recovery Algorithms", 1997, Obtain via: Retransmit, and Fast Recovery Algorithms", RFC 2001,
http://www.rfc-editor.org/rfc/rfc2001.txt January 1997. Obtain via: http://www.rfc-
editor.org/rfc/rfc2001.txt
[RFC2018] Mathis, M., Mahdavi, J. Floyd, S., Romanow, A., "TCP [RFC2018] Mathis, M., Mahdavi, J. Floyd, S., Romanow, A., "TCP
Selective Acknowledgment Options", 1996, Obtain via: Selective Acknowledgment Options", RFC 2018, October
http://www.rfc-editor.org/rfc/rfc2018.txt 1996. Obtain via: http://www.rfc-
editor.org/rfc/rfc2018.txt
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", 1997, Obtain via: Requirement Levels", BCP 14, RFC 2119, March 1997.
http://www.rfc-editor.org/rfc/rfc2119.txt Obtain via: http://www.rfc-editor.org/rfc/rfc2119.txt
[RFC2216] Shenker, S., Wroclawski, J., "Network Element Service [RFC2216] Shenker, S. and J. Wroclawski, "Network Element Service
Specification Template", 1997, Obtain via: Specification Template", RFC 2216, September 1997.
http://www.rfc-editor.org/rfc/rfc2216.txt Obtain via: http://www.rfc-editor.org/rfc/rfc2216.txt
[RFC2330] Paxson, V., Almes, G., Mahdavi, J., Mathis, M., "Framework [RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis,
for IP Performance Metrics" , 1998, Obtain via: "Framework for IP Performance Metrics", RFC 2330, April
http://www.rfc-editor.org/rfc/rfc2330.txt 1998. Obtain via: http://www.rfc-
editor.org/rfc/rfc2330.txt
[RFC2475] Black D., Blake S., Carlson M., Davies E., Wang Z., Weiss [RFC2475] Black D., Blake S., Carlson M., Davies E., Wang Z. and
W., "An Architecture for Differentiated Services", 1998, Obtain W. Weiss, "An Architecture for Differentiated Services",
via: http://www.rfc-editor.org/rfc/rfc2475.txt RFC 2475, December 1998. Obtain via: http://www.rfc-
editor.org/rfc/rfc2475.txt
[RFC2481] K. Ramakrishnan, S. Floyd, "A Proposal to add Explicit [RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add
Congestion Notification (ECN) to IP", 1999, Obtain via: Explicit Congestion Notification (ECN) to IP", RFC 2481,
http://www.rfc-editor.org/rfc/rfc2481.txt January 1999. Obtain via: http://www.rfc-
editor.org/rfc/rfc2481.txt
[RFC2525] V. Paxson, M. Allman, S. Dawson, W. Fenner, J. Griner, [RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner,
I. Heavens, K. Lahey, J. Semke, B. Volz, "Known TCP J., Heavens, I., Lahey, K., Semke, J. and B. Volz,
Implementation Problems", 1999, Obtain via: "Known TCP Implementation Problems", RFC 2525, March
http://www.rfc-editor.org/rfc/rfc2525.txt 1999. Obtain via: http://www.rfc-
editor.org/rfc/rfc2525.txt
[RFC2581] Allman, M., Paxson, V., Stevens, W., "TCP Congestion [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion
Control"., 1999, Obtain via: Control", RFC 2581, April 1999. Obtain via:
http://www.rfc-editor.org/rfc/rfc2581.txt http://www.rfc-editor.org/rfc/rfc2581.txt
[RFC2582] Floyd, S., Henderson, T., "The NewReno Modification to [RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to
TCP's Fast Recovery Algorithm", 1999, Obtain via: TCP's Fast Recovery Algorithm", RFC 2582, April 1999.
http://www.rfc-editor.org/rfc/rfc2582.txt Obtain via: http://www.rfc-editor.org/rfc/rfc2582.txt
[RFC2988] Paxson, V., Allman, M., "Computing TCP's Retransmission [RFC2988] Paxson, V. and M. Allman, "Computing TCP's
Timer", November 2000, Obtain via: Retransmission Timer", RFC 2988, November 2000. Obtain
http://www.rfc-editor.org/rfc/rfc2988.txt via: http://www.rfc-editor.org/rfc/rfc2988.txt
[RFC3042] Allman, M., Balakrishnan, H., Floyd, S., "Enhancing TCP's [RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing
Loss Recovery Using Limited Transmit", January 2001, Obtain via: TCP's Loss Recovery Using Limited Transmit", RFC 3042,
http://www.rfc-editor.org/rfc/rfc3042.txt January 2001. Obtain via: http://www.rfc-
editor.org/rfc/rfc3042.txt
[Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols", [Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The
Addison-Wesley, 1994. Protocols", Addison-Wesley, 1994.
[WS95] Wright, G., Stevens, W., "TCP/IP Illustrated Volume II: The [WS95] Wright, G., Stevens, W., "TCP/IP Illustrated Volume II:
Implementation", Addison-Wesley, 1995. The Implementation", Addison-Wesley, 1995.
Author's Addresses Author's Addresses
Matt Mathis Matt Mathis
Pittsburgh Supercomputing Center Pittsburgh Supercomputing Center
4400 Fifth Ave. 4400 Fifth Ave.
Pittsburgh PA 15213 Pittsburgh PA 15213
mathis@psc.edu
http://www.psc.edu/~mathis
Mark Allman EMail: mathis@psc.edu
BBN Technologies/NASA Glenn Research Center http://www.psc.edu/~mathis
Lewis Field
21000 Brookpark Rd. MS 54-2 Mark Allman
Cleveland, OH 44135 BBN Technologies/NASA Glenn Research Center
216-433-6586 Lewis Field
mallman@bbn.com 21000 Brookpark Rd. MS 54-2
http://roland.grc.nasa.gov/~mallman Cleveland, OH 44135
Phone: 216-433-6586
EMail: mallman@bbn.com
http://roland.grc.nasa.gov/~mallman
Full Copyright Statement
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 110 change blocks. 
486 lines changed or deleted 486 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/