diff options
Diffstat (limited to 'doc/rfc/rfc3148.txt')
| -rw-r--r-- | doc/rfc/rfc3148.txt | 899 |
1 files changed, 899 insertions, 0 deletions
diff --git a/doc/rfc/rfc3148.txt b/doc/rfc/rfc3148.txt new file mode 100644 index 0000000..fa49167 --- /dev/null +++ b/doc/rfc/rfc3148.txt @@ -0,0 +1,899 @@ + + + + + + +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 + of data (which would clearly require a retransmit timeout) TCP likely + missed some opportunity to safely transmit data. That is, if TCP + 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 + partial data was delivered, but did not trigger the transmission of + new data. Recent research in congestion control (e.g., FACK [MM96a], + NewReno [FF96,RFC2582], rate-halving [MSML99]) can be characterized + as making TCP's Self-Clock more tenacious, while preserving fairness + under adverse conditions. This work is motivated by how poorly + current TCP implementations perform under some conditions, often due + to repeated clock loss. Since this is an active research area, + different TCP implementations have rather considerable differences in + their ability to preserve Self-Clock. + +3.2 Preservation of Self-Clock + + 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 + recovery algorithm. Therefore, the transition between timer driven + and Self-Clocked operation SHOULD be instrumented. + +3.2.1 Lost Transmission Opportunities + + If the last event before a timeout was the receipt of an ACK that did + not trigger a transmission, the possibility exists that an alternate + congestion control algorithm would have successfully preserved the + Self-Clock. A BTC SHOULD instrument key items in the BTC state (such + as the congestion window) in the hopes that this may lead to further + improvements in congestion control algorithms. + + + + + + + + +Mathis, et al. Informational [Page 6] + +RFC 3148 Framework for Defining Empirical BTC Metrics July 2001 + + + Note that in the absence of knowledge about the future, it is not + possible to design an algorithm that never misses transmission + opportunities. However, there are ever more subtle ways to gauge + network state, and to estimate if a given ACK is likely to be the + last. + +3.2.2 Loosing an Entire Window + + If an entire window of data (or ACKs) is lost, there will be no + returning ACKs to clock out additional data. This condition can be + detected if the last event before a timeout was a data transmission + triggered by an ACK. The loss of an entire window of data/ACKs + forces recovery to be via a Retransmission Timeout and Slow-Start. + + 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 + diagnosed with low rate metrics and is unsafe to diagnose at higher + rates than the BTC. Therefore all BTC metrics SHOULD instrument and + report losses of an entire window of data. + + Note that there are some conditions, such as when operating with a + very small window, in which there is a significant probability that + an entire window can be lost through individual random losses (again + highlighting the importance of instrumenting cwnd). + +3.2.3 Heroic Clock Preservation + + All algorithms that permit a given BTC to sustain Self-Clock when + other algorithms might not, SHOULD be instrumented. Furthermore, the + details of the algorithms used MUST be fully documented (as discussed + in section 2). + + BTC metrics that can sustain Self-Clock in the presence of multiple + losses within one round trip SHOULD instrument the loss distribution, + such that the performance of alternate congestion control algorithms + may be estimated (e.g., Reno style). + +3.2.4 False Timeouts + + All false timeouts, (where the retransmission timer expires before + the ACK for some previously transmitted data arrives) SHOULD be + instrumented when possible. Note that depending upon how the BTC + metric implements sequence numbers, this may be difficult to detect. + + + + + + + + +Mathis, et al. Informational [Page 7] + +RFC 3148 Framework for Defining Empirical BTC Metrics July 2001 + + +3.3 Ancillary Metrics Relating to Flow Based Path Properties + + All BTC metrics provide unique vantage points for observing certain + path properties relating to closely spaced packets. As in the case + 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 + above the BTC of the network path. + + All BTC metrics SHOULD instrument packet reordering. The frequency + and distance out-of-sequence SHOULD be instrumented for all out-of- + order packets. The severity of the reordering can be classified as + one of three different cases, each of which SHOULD be reported. + + Segments that are only slightly out-of-order should not trigger + the fast retransmit algorithm, but they may affect the window + calculation. BTC metrics SHOULD document how slightly out-of- + order segments affect the congestion window calculation. + + If segments are sufficiently out-of-order, the Fast Retransmit + algorithm will be invoked in advance of the delayed packet's late + arrival. These events SHOULD be instrumented. Even though the + the late arriving packet will complete recovery, the the window + will still be reduced by half. + + Under some rare conditions segments have been observed that are + far out of order - sometimes many seconds late [Pax97b]. These + SHOULD always be instrumented. + + BTC implementations SHOULD instrument the maximum cwnd observed + during congestion avoidance and slow start. A TCP running over the + same path as the BTC metric must have sufficient sender buffer space + and receiver window (and window shift [RFC1323]) to cover this cwnd + in order to expect the same performance. + + There are several other path properties that one might measure within + a BTC metric. For example, with an embedded one-way delay metric it + may be possible to measure how queuing delay and and (RED) drop + probabilities are correlated to window size. These are open research + questions. + +3.4 Ancillary Metrics as Calibration Checks + + Unlike low rate metrics, BTC SHOULD include explicit checks that the + test platform is not the bottleneck. + + Any detected dropped packets within the sending host MUST be + reported. Unless the sending interface is the path bottleneck, any + dropped packets probably indicates a measurement failure. + + + +Mathis, et al. Informational [Page 8] + +RFC 3148 Framework for Defining Empirical BTC Metrics July 2001 + + + The maximum queue lengths within the sending host SHOULD be + instrumented. Any significant queue may indicate that the sending + host has insufficient burst data rate, and is smoothing the data + being transmitted into the network. + +3.5 Ancillary Metrics Relating to the Need for Advanced TCP Features + + If TCP would require advanced TCP extensions to match BTC performance + (such as RFC 1323 or RFC 2018 features), it SHOULD be reported. + +3.6 Validate Reverse Path Load + + To the extent possible, the BTC metric SHOULD distinguish between the + properties of the forward and reverse paths. + + BTC methodologies which rely on non-cooperating receivers may only be + able to measure round trip path properties and may not be able to + independently differentiate between the properties of the forward and + reverse paths. In this case the load on the reverse path contributed + by the BTC metric SHOULD be instrumented (or computed) to permit + other means of gauge the proportion of the round trip path properties + attributed to the the forward and reverse paths. + + To the extent possible, BTC methodologies that rely on cooperating + receivers SHOULD support separate ancillary metrics for the forward + and reverse paths. + +4 Security Considerations + + Conducting Internet measurements raises security concerns. This memo + does not specify a particular implementation of a metric, so it does + not directly affect the security of the Internet nor of applications + which run on the Internet. However, metrics produced within this + framework, and in particular implementations of the metrics may + create security issues. + +4.1 Denial of Service Attacks + + 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. + + + + + + + +Mathis, et al. Informational [Page 9] + +RFC 3148 Framework for Defining Empirical BTC Metrics July 2001 + + + 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. + +4.2 User data confidentiality + + Metrics within this framework generate packets for a sample, rather + 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. + + Matt Mathis's work was supported by the National Science Foundation + under Grant Numbers 9415552 and 9870758. + + + + + + + + + + +Mathis, et al. Informational [Page 10] + +RFC 3148 Framework for Defining Empirical BTC Metrics July 2001 + + +7 References + + [BPS+97] Hari Balakrishnan, Venkata Padmanabhan, Srinivasan + Seshan, Mark Stemm, and Randy Katz. TCP Behavior of a + Busy Web Server: Analysis and Improvements. Technical + Report UCB/CSD-97-966, August 1997. Available from + http://nms.lcs.mit.edu/~hari/papers/csd-97-966.ps. + (Also in Proc. IEEE INFOCOM Conf., San Francisco, CA, + March 1998.) + + [FF96] Fall, K., Floyd, S.. "Simulation-based Comparisons of + Tahoe, Reno and SACK TCP". Computer Communication + Review, July 1996. + ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z. + + [Flo95] Floyd, S., "TCP and successive fast retransmits", March + 1995, Obtain via + ftp://ftp.ee.lbl.gov/papers/fastretrans.ps. + + [Hoe96] Hoe, J., "Improving the start-up behavior of a + congestion control scheme for TCP, Proceedings of ACM + SIGCOMM '96, August 1996. + + [Hoe95] Hoe, J., "Startup dynamics of TCP's congestion control + and avoidance schemes". Master's thesis, Massachusetts + Institute of Technology, June 1995. + + [Jac88] Jacobson, V., "Congestion Avoidance and Control", + Proceedings of SIGCOMM '88, Stanford, CA., August 1988. + + [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: + Analysis and Improvements", Proceedings of InfoCom, + March 1998. + + [LM97] T.V.Lakshman and U.Madhow. "The Performance of TCP/IP + for Networks with High Bandwidth-Delay Products and + Random Loss". IEEE/ACM Transactions on Networking, Vol. + 5, No. 3, June 1997, pp.336-350. + + + + + + + + +Mathis, et al. Informational [Page 11] + +RFC 3148 Framework for Defining Empirical BTC Metrics July 2001 + + + [Mat98] Mathis, M., "Empirical Bulk Transfer Capacity", IP + Performance Metrics Working Group report in Proceedings + of the Forty Third Internet Engineering Task Force, + Orlando, FL, December 1988. Available from + http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec- + 122.html and + http://www.ietf.org/proceedings/98dec/slides/ippm- + mathis-98dec.pdf. + + [MM96a] Mathis, M. and Mahdavi, J. "Forward acknowledgment: + Refining TCP congestion control", Proceedings of ACM + SIGCOMM '96, Stanford, CA., August 1996. + + [MM96b] M. Mathis, J. Mahdavi, "TCP Rate-Halving with Bounding + Parameters". Available from + http://www.psc.edu/networking/papers/FACKnotes/current. + + [MSML99] Mathis, M., Semke, J., Mahdavi, J., Lahey, K., "The + Rate-Halving Algorithm for TCP Congestion Control", June + 1999, Work in Progress. + + [MSMO97] Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The + Macroscopic Behavior of the TCP Congestion Avoidance + Algorithm", Computer Communications Review, 27(3), July + 1997. + + [OKM96a], Ott, T., Kemperman, J., Mathis, M., "The Stationary + Behavior of Ideal TCP Congestion Avoidance", In + progress, August 1996. Obtain via pub/tjo/TCPwindow.ps + using anonymous ftp to ftp.bellcore.com + + [OKM96b], Ott, T., Kemperman, J., Mathis, M., "Window Size + Behavior in TCP/IP with Constant Loss Probability", + DIMACS Special Year on Networks, Workshop on Performance + of Real-Time Applications on the Internet, Nov 1996. + + [Pax97a] Paxson, V., "Automated Packet Trace Analysis of TCP + Implementations", Proceedings of ACM SIGCOMM '97, August + 1997. + + [Pax97b] Paxson, V., "End-to-End Internet Packet Dynamics," + Proceedings of SIGCOMM '97, Cannes, France, Sep. 1997. + + [PFTK98] Padhye, J., Firoiu. V., Towsley, D., and Kurose, J., + "TCP Throughput: A Simple Model and its Empirical + Validation", Proceedings of ACM SIGCOMM '98, August + 1998. + + + + +Mathis, et al. Informational [Page 12] + +RFC 3148 Framework for Defining Empirical BTC Metrics July 2001 + + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC + 793, September 1981. Obtain via: http://www.rfc- + editor.org/rfc/rfc793.txt + + [RFC1191] Mogul, J. and S. Deering, "Path MTU Discovery", RFC + 1191, November 1990. Obtain via: http://www.rfc- + editor.org/rfc/rfc1191.txt + + [RFC1323] Jacobson, V., Braden, R. and D. Borman, "TCP Extensions + for High Performance", May 1992. Obtain via: + http://www.rfc-editor.org/rfc/rfc1323.txt + + [RFC1633] Braden R., Clark D. and S. Shenker, "Integrated Services + in the Internet Architecture: an Overview", RFC 1633, + June 1994. Obtain via: http://www.rfc- + editor.org/rfc/rfc1633.txt + + [RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast + Retransmit, and Fast Recovery Algorithms", RFC 2001, + January 1997. Obtain via: http://www.rfc- + editor.org/rfc/rfc2001.txt + + [RFC2018] Mathis, M., Mahdavi, J. Floyd, S., Romanow, A., "TCP + Selective Acknowledgment Options", RFC 2018, October + 1996. Obtain via: http://www.rfc- + editor.org/rfc/rfc2018.txt + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + Obtain via: http://www.rfc-editor.org/rfc/rfc2119.txt + + [RFC2216] Shenker, S. and J. Wroclawski, "Network Element Service + Specification Template", RFC 2216, September 1997. + Obtain via: http://www.rfc-editor.org/rfc/rfc2216.txt + + [RFC2330] Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, + "Framework for IP Performance Metrics", RFC 2330, April + 1998. Obtain via: http://www.rfc- + editor.org/rfc/rfc2330.txt + + [RFC2475] Black D., Blake S., Carlson M., Davies E., Wang Z. and + W. Weiss, "An Architecture for Differentiated Services", + RFC 2475, December 1998. Obtain via: http://www.rfc- + editor.org/rfc/rfc2475.txt + + + + + + + +Mathis, et al. Informational [Page 13] + +RFC 3148 Framework for Defining Empirical BTC Metrics July 2001 + + + [RFC2481] Ramakrishnan, K. and S. Floyd, "A Proposal to add + Explicit Congestion Notification (ECN) to IP", RFC 2481, + January 1999. Obtain via: http://www.rfc- + editor.org/rfc/rfc2481.txt + + [RFC2525] Paxson, V., Allman, M., Dawson, S., Fenner, W., Griner, + J., Heavens, I., Lahey, K., Semke, J. and B. Volz, + "Known TCP Implementation Problems", RFC 2525, March + 1999. Obtain via: http://www.rfc- + editor.org/rfc/rfc2525.txt + + [RFC2581] Allman, M., Paxson, V. and W. Stevens, "TCP Congestion + Control", RFC 2581, April 1999. Obtain via: + http://www.rfc-editor.org/rfc/rfc2581.txt + + [RFC2582] Floyd, S. and T. Henderson, "The NewReno Modification to + TCP's Fast Recovery Algorithm", RFC 2582, April 1999. + Obtain via: http://www.rfc-editor.org/rfc/rfc2582.txt + + [RFC2988] Paxson, V. and M. Allman, "Computing TCP's + Retransmission Timer", RFC 2988, November 2000. Obtain + via: http://www.rfc-editor.org/rfc/rfc2988.txt + + [RFC3042] Allman, M., Balakrishnan, H. and S. Floyd, "Enhancing + TCP's Loss Recovery Using Limited Transmit", RFC 3042, + January 2001. Obtain via: http://www.rfc- + editor.org/rfc/rfc3042.txt + + [Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The + Protocols", Addison-Wesley, 1994. + + [WS95] Wright, G., Stevens, W., "TCP/IP Illustrated Volume II: + The Implementation", Addison-Wesley, 1995. + + + + + + + + + + + + + + + + + + +Mathis, et al. Informational [Page 14] + +RFC 3148 Framework for Defining Empirical BTC Metrics July 2001 + + +Author's Addresses + + Matt Mathis + Pittsburgh Supercomputing Center + 4400 Fifth Ave. + Pittsburgh PA 15213 + + EMail: mathis@psc.edu + http://www.psc.edu/~mathis + + + Mark Allman + BBN Technologies/NASA Glenn Research Center + Lewis Field + 21000 Brookpark Rd. MS 54-2 + Cleveland, OH 44135 + + Phone: 216-433-6586 + EMail: mallman@bbn.com + http://roland.grc.nasa.gov/~mallman + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Mathis, et al. Informational [Page 15] + +RFC 3148 Framework for Defining Empirical BTC Metrics July 2001 + + +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. + + + + + + + + + + + + + + + + + + + +Mathis, et al. Informational [Page 16] + |