draft-ietf-ippm-btc-framework-04.txt   draft-ietf-ippm-btc-framework-05.txt 
INTERNET-DRAFT Expires May 2001 INTERNET-DRAFT INTERNET-DRAFT Expires May 2001 INTERNET-DRAFT
Network Working Group Matt Mathis Network Working Group Matt Mathis
INTERNET-DRAFT Pittsburgh Supercomputing Center INTERNET-DRAFT Pittsburgh Supercomputing Center
Expiration Date: May 2001 Mark Allman Expiration Date: May 2001 Mark Allman
NASA Glenn/BBN BBN/NASA Glenn
December, 2000 February, 2001
A Framework for Defining Empirical Bulk Transfer Capacity Metrics A Framework for Defining Empirical Bulk Transfer Capacity Metrics
< draft-ietf-ippm-btc-framework-04.txt > < draft-ietf-ippm-btc-framework-05.txt >
Status of this Document Status of this Document
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
skipping to change at line 82 skipping to change at line 82
elapsed time for the application to run and thus dominates the elapsed time for the application to run and thus dominates the
performance as perceived by a user. Examples of such applications performance as perceived by a user. Examples of such applications
include FTP, and the world wide web when delivering large images or include FTP, and the world wide web when delivering large images or
documents. The intuitive definition of BTC is the expected long documents. The intuitive definition of BTC is the expected long
term average data rate (bits per second) of a single ideal TCP term average data rate (bits per second) of a single ideal TCP
implementation over the path in question. The specific definition implementation over the path in question. The specific definition
of the bulk transfer capacity that MUST be reported by a BTC tool is: of the bulk transfer 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'' bytes transfered where ``data_sent'' represents the unique ``data'' bits transfered
(i.e., not including header bytes or emulated header bytes). Also (i.e., not including header bits or emulated header bits). Also
note that the amount of data sent should only include the unique note that the amount of data sent should only include the unique
number of bytes transmitted (i.e., if a particular packet is number of bits transmitted (i.e., if a particular packet is
retransmitted the data it contains should be counted only once). retransmitted the data 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 transport protocols should have similar responses to congestion all transport protocols should have similar responses to congestion
in the Internet. Indeed the only form of equity significantly in the Internet. Indeed the only form of equity significantly
deployed in the Internet today is that the vast majority of all deployed in the Internet today is that the vast majority of all
traffic is carried by TCP implementations sharing common congestion traffic is carried by TCP implementations sharing common congestion
control algorithms largely due to a shared developmental heritage. control algorithms largely due to a shared developmental heritage.
[RFC2581] specifies the standard congestion control algorithms used [RFC2581] specifies the standard congestion control algorithms used
skipping to change at line 122 skipping to change at line 122
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-linearity (in either TCP or a BTC metric) is potentially non-linearity (in either TCP or a BTC metric) is potentially
problematic in the market because investment in capacity might problematic in the market because investment in capacity might
actually reduce the perceived quality of the network. Ongoing actually reduce the perceived quality of the network. Ongoing
research in congestion dynamics has some hope of mitigating or research in congestion dynamics has some hope of mitigating or
modeling the these non-linearities. modeling the these non-linearities.
Related areas, including Integrated services Related areas, including integrated services
[RFC1633,RFC2216], differentiated services [RFC2475] and Internet [RFC1633,RFC2216], differentiated services [RFC2475] and Internet
traffic analysis [MSMO97,PFTK98,Pax97b,LM97] are all currently traffic analysis [MSMO97,PFTK98,Pax97b,LM97] are all currently
receiving significant attention from the research community. It is receiving significant attention from the research community. It is
likely that we will see new experimental congestion control likely that we will see new experimental congestion control
algorithms in the near future. In addition, Explicit Congestion algorithms in the near future. In addition, Explicit Congestion
Notification (ECN) [RFC2481] is being tested for Internet Notification (ECN) [RFC2481] is being tested for Internet
deployment. We do not yet know how any of these developments might deployment. We do not yet know how any of these developments might
affect BTC metrics, and thus the BTC framework and metrics may need affect BTC metrics, and thus the BTC framework and metrics may need
to be revisited in the future. to be revisited in the future.
skipping to change at line 195 skipping to change at line 195
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]. 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 * [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. 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 specified.
In addition, if the segment size is artificially limited to less In addition, if the segment size is artificially limited to less
skipping to change at line 228 skipping to change at line 229
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 which
MUST be specified for each BTC metric defined. 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
skipping to change at line 250 skipping to change at line 251
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.3). 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 rather substantial difficulty with using it as such. The a rather substantial difficulty with using it as such. The
Self-Clocking of the Congestion Avoidance algorithm can be very Self-Clocking of the Congestion Avoidance algorithm can be very
fragile, depending on the specific details of the Fast Retransmit, fragile, depending on the specific details of the Fast Retransmit,
Fast Recovery or advanced recovery algorithms chosen. It has been Fast Recovery or advanced recovery algorithms chosen. It has been
found that timeouts and periods of slow start loss recovery are found that timeouts and periods of slow start loss recovery are
prevalent in traffic on the Internet [LK98,BPS+97] and therefore these prevalent in traffic on the Internet [LK98,BPS+97] and therefore these
should be captured by the BTC metric. should be captured by the BTC metric.
skipping to change at line 421 skipping to change at line 422
contributed by the BTC metric SHOULD be instrumented (or computed) contributed by the BTC metric SHOULD be instrumented (or computed)
to permit other means of gauge the proportion of the round trip path to permit other means of gauge the proportion of the round trip path
properties attributed to the the forward and reverse paths. properties 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
The framework for specifying BTC metrics outlined in this document Conducting Internet measurements raises security concerns. This
does not pose any threat to Internet security. The BTC metrics memo does not specify a particular implementation of a metric, so it
defined based on this specification will be as ``network friendly'' does not directly affect the security of the Internet nor of
as current TCP connections. applications which run on the Internet. However, metrics produced
within this framework, and in particular implementations of the
metrics may create security issues.
5 Acknowledgments 4.1 Denial of Service Attacks
Thanks to Jeff Semke for numerous clarifications. Bulk Transport Capacity metrics, as defined in this document,
naturally attempt to fill a bottleneck link. The BTC metrics based
on this specification will be as ``network friendly'' as current
well-tuned TCP connections. However, since the ``connection'' may
not be using TCP packets, a BTC test may appear to network operators
as a denial of service attack.
6 References Administrators of the source host of a test, the destination host of
a test, and the intervening network(s) may wish to establish
bilateral or multi-lateral agreements regarding the timing, size,
and frequency of collection of BTC metrics.
[ABF00] Mark Allman, Hari Balakrishnan, Sally Floyd. Enhancing 4.2 User data confidentiality
TCP's Loss Recovery Using Limited Transmit, August
2000. Internet-Draft draft-ietf-tsvwg-limited-xmit-00.txt (work Metrics within this framework generate packets for a sample, rather
in progress). than taking samples based on user data. Thus, a BTC metric does not
threaten user data confidentiality.
4.3 Interference with metrics
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
destination and/or the intervening networks, it is possible to
change the processing of the packets (e.g. increasing or decreasing
delay, introducing or heroically preventing loss) that may distort
the measured performance. It may also be possible to generate
additional packets that appear to be part of a BTC metric. These
additional packets are likely to perturb the results of the sample
measurement.
To discourage the kind of interference mentioned above, packet
interference checks, such as cryptographic hash, may be used.
5 IANA Considerations
Since this metric framework does not define a specific
protocol, nor does it define any well-known values, there
are no IANA considerations for this document. However,
a bulk transport capacity metric within this framework,
and in particular protocols that implement a metric may have
IANA considerations that need to be addressed.
6 Acknowledgments
Thanks to Wil Leland, Jeff Semke, Matt Zekauskas and the IPPM
working group for numerous clarifications.
7 References
[BPS+97] Hari Balakrishnan, Venkata Padmanabhan, Srinivasan Seshan, [BPS+97] Hari Balakrishnan, Venkata Padmanabhan, Srinivasan Seshan,
Mark Stemm, and Randy Katz. TCP Behavior of a Busy Web Server: Mark Stemm, and Randy Katz. TCP Behavior of a Busy Web Server:
Analysis and Improvements. Technical Report UCB/CSD-97-966, Analysis and Improvements. Technical Report UCB/CSD-97-966,
August 1997. Available from 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. (Also in
Proc. IEEE INFOCOM Conf., San Francisco, CA, March 1998.) 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 Tahoe,
Reno and SACK TCP". Computer Communication Review, July 1996. Reno and SACK TCP". Computer Communication Review, July 1996.
skipping to change at line 518 skipping to change at line 561
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., "TCP
Throughput: A Simple Model and its Empirical Validation", Throughput: A Simple Model and its Empirical Validation",
Proceedings of ACM SIGCOMM '98, August 1998. Proceedings of ACM SIGCOMM '98, August 1998.
[RFC793] Postel, J., "Transmission Control Protocol", 1981, Obtain [RFC793] Postel, J., "Transmission Control Protocol", 1981, Obtain
via: ftp://ds.internic.net/rfc/rfc793.txt via: http://www.rfc-editor.org/rfc/rfc793.txt
[RFC1191] Mogul, J., Deering, S., "Path MTU Discovery", November [RFC1191] Mogul, J., Deering, S., "Path MTU Discovery", November
1990, Obtain via: ftp://ds.internic.net/rfc/rfc1191.txt 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., Borman, D., "TCP Extensions for
High Performance", May 1992, Obtain via: High Performance", May 1992, Obtain via:
ftp://ds.internic.net/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., Shenker S., "Integrated Services in
the Internet Architecture: an Overview"., 1994. the Internet Architecture: an Overview", 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", 1997, Obtain via:
ftp://ds.internic.net/rfc/rfc2001.txt 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", 1996, Obtain via:
ftp://ds.internic.net/rfc/rfc2018.txt 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", 1997, Obtain via:
ftp://ds.internic.net/rfc/rfc2119.txt http://www.rfc-editor.org/rfc/rfc2119.txt
[RFC2216] Shenker, S., Wroclawski, J., "Network Element Service [RFC2216] Shenker, S., Wroclawski, J., "Network Element Service
Specification Template", 1997, Obtain via: Specification Template", 1997, Obtain via:
ftp://ds.internic.net/rfc/rfc2216.txt 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., Mathis, M., "Framework
for IP Performance Metrics" , 1998, Obtain via: for IP Performance Metrics" , 1998, Obtain via:
ftp://ds.internic.net/rfc/rfc2330.txt 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., Weiss
W., "An Architecture for Differentiated Services"., 1998. W., "An Architecture for Differentiated Services", 1998, Obtain
via: http://www.rfc-editor.org/rfc/rfc2475.txt
[RFC2481] K. Ramakrishnan, S. Floyd, "A Proposal to add Explicit [RFC2481] K. Ramakrishnan, S. Floyd, "A Proposal to add Explicit
Congestion Notification (ECN) to IP", 1999, Obtain via: Congestion Notification (ECN) to IP", 1999, Obtain via:
ftp://ds.internic.net/rfc/rfc2481.txt http://www.rfc-editor.org/rfc/rfc2481.txt
[RFC2525] V. Paxson, M. Allman, S. Dawson, W. Fenner, J. Griner, [RFC2525] V. Paxson, M. Allman, S. Dawson, W. Fenner, J. Griner,
I. Heavens, K. Lahey, J. Semke, B. Volz, "Known TCP I. Heavens, K. Lahey, J. Semke, B. Volz, "Known TCP
Implementation Problems", 1999, Obtain via: Implementation Problems", 1999, Obtain via:
ftp://ds.internic.net/rfc/rfc2525.txt http://www.rfc-editor.org/rfc/rfc2525.txt
[RFC2581] Allman, M., Paxson, V., Stevens, W., "TCP Congestion [RFC2581] Allman, M., Paxson, V., Stevens, W., "TCP Congestion
Control"., 1999, Obtain via: Control"., 1999, Obtain via:
ftp://ds.internic.net/rfc/rfc2581.txt http://www.rfc-editor.org/rfc/rfc2581.txt
[RFC2582] Floyd, S., Henderson, T., "The NewReno Modification to [RFC2582] Floyd, S., Henderson, T., "The NewReno Modification to
TCP's Fast Recovery Algorithm", 1999, Obtain via: TCP's Fast Recovery Algorithm", 1999, Obtain via:
ftp://ds.internic.net/rfc/rfc2582.txt http://www.rfc-editor.org/rfc/rfc2582.txt
[RFC2988] Paxson, V., Allman, M., "Computing TCP's Retransmission [RFC2988] Paxson, V., Allman, M., "Computing TCP's Retransmission
Timer", November 2000, Obtain via: Timer", November 2000, Obtain via:
ftp://ds.internic.net/rfc/rfc2988.txt http://www.rfc-editor.org/rfc/rfc2988.txt
[RFC3042] Allman, M., Balakrishnan, H., Floyd, S., "Enhancing TCP's
Loss Recovery Using Limited Transmit", 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 Protocols",
Addison-Wesley, 1994. Addison-Wesley, 1994.
[WS95] Wright, G., Stevens, W., "TCP/IP Illustrated Volume II: The [WS95] Wright, G., Stevens, W., "TCP/IP Illustrated Volume II: The
Implementation", Addison-Wesley, 1995. 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 mathis@psc.edu
http://www.psc.edu/~mathis http://www.psc.edu/~mathis
Mark Allman Mark Allman
NASA Glenn Research Center/BBN Technologies BBN Technologies/NASA Glenn Research Center
Lewis Field Lewis Field
21000 Brookpark Rd. MS 54-2 21000 Brookpark Rd. MS 54-2
Cleveland, OH 44135 Cleveland, OH 44135
216-433-6586 216-433-6586
mallman@grc.nasa.gov mallman@bbn.com
http://roland.grc.nasa.gov/~mallman http://roland.grc.nasa.gov/~mallman
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/