RFC 3148

Part 1 of 3 💖 more coming, bestie!

RFC 3148: A Framework for Defining Empirical Bulk Transfer Capacity Metrics ✨

okay so first, the title block tea ☕ This one is RFC 3148, titled A Framework for Defining Empirical Bulk Transfer Capacity Metrics. It was written by M. Mathis (Pittsburgh Supercomputing Center) and M. Allman (BBN/NASA Glenn). It's Informational and dated July 2001. The title block doesn't list anything it obsoletes or updates, so there's nothing to report there 🫶

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 sets up a framework for standardizing multiple BTC (Bulk Transport Capacity) metrics that line up with the transport diversity the IETF allows. so many metrics, one framework 🦋

1. Introduction 💅

Okay, so Bulk Transport Capacity (BTC) measures how well a network can move a big pile of data over a single congestion-aware transport connection (for example, TCP). The vibe is: the expected long-term average data rate, in bits per second, of one ideal TCP implementation over the path you're looking at. 🧚

The catch is that the IETF allows lots of congestion control algorithms (and so lots of transport implementations). That diversity is a whole problem for standardizing BTC metrics. Different implementations can end up giving you numbers that can't be compared, and they might not even pass the formal tests to count as a metric. 😭

So there are two approaches here. First, every BTC metric has to be way more tightly specified than your typical IETF protocol. Second, every BTC methodology is expected to also collect some ancillary metrics that could help with 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]. [RFC2119] was written with protocols in mind, but these key words get used here for similar reasons. They make sure each BTC methodology has specific pieces of information included. 🎀

Okay, so BTC is still the same idea: a network's ability to move significant amounts of data over one congestion-aware transport connection (e.g., TCP). For lots of applications, BTC of the underlying network totally dominates how long the app takes to run, which means it's basically what a user feels as performance. Think FTP, or the web when it's loading big images or documents. The intuitive definition is still the expected long-term average data rate (bits per second) of one ideal TCP implementation over the path in question. ✨

Here's the exact definition that a BTC tool MUST report:

BTC = data_sent / elapsed_time

where "data_sent" is the unique "data" bits transfered (so not header bits, and not emulated header bits). Also, the amount of data sent should only count the unique bits transmitted. If a packet gets retransmitted, the data in it should only be counted once. no double counting, periodt 💖

Central to all this is the idea that every transport protocol should respond to congestion in similar ways across the Internet. Honestly, the only kind of fairness that's really deployed on the Internet today is that most traffic is carried by TCP implementations that share common congestion control algorithms, mostly because they have a shared developmental heritage. 🌈

[RFC2581] specifies the standard congestion control algorithms used by TCP implementations. Even though this document is a (proposed) standard, it allows a lot of room in how you implement it. That room is on purpose, so congestion control algorithms can keep evolving. 🦋

This legal diversity in congestion control algorithms creates a problem for standardizing BTC metrics. The allowed diversity is big enough that different implementations can yield non-comparable measures, and they might potentially fail the formal tests for being a metric. 😬

There's also evidence that most TCP implementations show non-linear performance over some part of their operating region. You can build simple simulation examples where a small improvement to a path (like raising the link data rate) actually makes overall TCP throughput (or BTC) go down [Mat98]. 🙈

We believe this non-linearity reflects a weakness in our current understanding of congestion control. It's present to some extent in all TCP implementations and BTC metrics. Non-linearity (in either TCP or a BTC metric) can be a real problem in the market, because investing in capacity might actually reduce the perceived quality of the network. Ongoing research in congestion dynamics has some hope of mitigating or modeling these non-linearities. 📈

Related areas are also getting a lot of research attention right now: integrated services [RFC1633,RFC2216], differentiated services [RFC2475], and Internet traffic analysis [MSMO97,PFTK98,Pax97b,LM97]. We'll probably see new experimental congestion control algorithms soon. Also, Explicit Congestion Notification (ECN) [RFC2481] is being tested for Internet deployment. We don't know yet how any of these will affect BTC metrics, so the BTC framework and metrics might need to be revisited later. 👑

Alright, so this document defines a framework for standardizing multiple BTC metrics that match the permitted transport diversity. Two approaches again: 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 that are potentially useful for supporting analytical models of BTC. If a BTC methodology doesn't collect these ancillary metrics, it should collect enough information that the metrics can be derived anyway (for instance, a segment trace file). 🫶

For example, the models in [PFTK98, MSMO97, OKM96a, Lak94] all predict bulk transfer performance based on path properties like loss rate and round trip time. A BTC methodology that also gives ancillary measures of these properties is stronger, because agreement with the analytical models can be used to back up the direct BTC measurement results. 💅

Even more importantly, ancillary metrics are expected to help resolve disagreements between different BTC methodologies. For example, a path that mostly has clustered packet losses will likely show very different measures from BTC metrics that mimic the Tahoe, Reno, NewReno, and SACK TCP algorithms [FF96]. The differences over a path like that might be diagnosed with an ancillary measure of loss clustering. 🔍

Some path properties are best measured as ancillary metrics to a transport protocol. Examples include bottleneck queue limits or the tendency to reorder packets. These are hard or impossible to measure at low rates, and unsafe to measure at rates higher than the bulk transport capacity of the path. ⚠️

At some point in the future, there's expected to be an A-frame [RFC2330] that unifies all the simple path metrics (e.g., segment loss rates, round trip time) and BTC ancillary metrics (e.g., queue size and packet reordering) with the different versions of BTC metrics (e.g., the ones that parallel Reno or SACK TCP). It's giving unified framework energy 🌟

2. Congestion Control Algorithms 🎀

Almost every TCP implementation in use today uses the congestion control algorithms published in [Jac88] and further refined in [RFC2581]. On top of the basic ACK clock idea, 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 some 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. ✨

[RFC2581] gives implementers some choices in the details of how they implement things. The list below covers details about the congestion control algorithms that are either underspecified in [RFC2581] or very important to define when you're building a BTC methodology. These details MUST be specifically defined in each BTC methodology. 💖

• [RFC2581] doesn't standardize a specific algorithm for increasing cwnd during congestion avoidance. It gives several candidate algorithms. The algorithm used in a particular BTC methodology MUST be defined.
• [RFC2581] doesn't 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 mechanisms 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.
• The actual segment size, or the 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 haven't been acknowledged within an appropriate amount of time and haven't 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 get 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 give additional information about the network, and about how the implemented congestion control algorithms behave in response to what the network path is doing. It is RECOMMENDED that these metrics be built into each BTC methodology. Alternatively, it is RECOMMENDED that the BTC implementation provide enough information 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 ✨

okay so the "Congestion Avoidance Capacity" (CAC) metric is the data rate (bits per second) of a fully specified implementation of the Congestion Avoidance algorithm, with one big rule: the Retransmission Timeout and Slow-Start algorithms are not invoked 💅 CAC has no meaning across Retransmission Timeouts or Slow-Start periods, except for that single segment of Slow-Start that's allowed to follow recovery (we talk about it in section 2) 🦋

in principle CAC would be the ideal BTC metric bc it captures what TCP's steady state behavior should be 🌸 but there's a pretty big catch. the Self-Clocking of Congestion Avoidance can be super fragile, and it depends on the exact details of the Fast Retransmit, Fast Recovery, or advanced recovery algorithms you pick 🙈 people have found that timeouts and slow start loss recovery are everywhere on the Internet [LK98,BPS+97], so the BTC metric should capture them too, obviously ✨

when TCP loses its Self-Clock, it gets it back through a retransmission timeout and Slow-Start. those almost always take longer than Congestion Avoidance would have 😭 it's pretty easy to see that unless the network drops a whole window of data (which would clearly need a retransmit timeout), TCP probably missed a chance to safely send data. like, if TCP times out after losing a partial window, it must have gotten at least one ACK that came after some of the partial data arrived, but that ACK didn't trigger any new data 💀 recent congestion control research (FACK [MM96a], NewReno [FF96,RFC2582], rate-halving [MSML99]) basically makes TCP's Self-Clock more tenacious while still keeping things fair when conditions are rough 🔥 this work is motivated by how badly current TCP implementations do in some situations, often because they keep losing the clock 😤 since this is an active research area, different TCP implementations are really different in how well they hang onto Self-Clock 🌈

3.2 Preservation of Self-Clock 🫶

losing the ACK clock can seriously hurt the overall BTC, and the clock is fragile in ways that depend on the loss recovery algorithm. so the switch between timer driven operation and Self-Clocked operation SHOULD be instrumented 💜

3.2.1 Lost Transmission Opportunities 🦋

if the last thing that happened before a timeout was receiving an ACK that didn't trigger a transmission, then a different congestion control algorithm might have kept the Self-Clock going 👀 so a BTC SHOULD instrument key parts of the BTC state (like the congestion window) in the hopes that this leads to better congestion control algorithms later 🔥

not gonna lie, you can't predict the future, so no algorithm can avoid missing every transmission opportunity 🙃 BUT there are more and more clever ways to read network state and guess whether a given ACK is probably the last one 🧚

3.2.2 Loosing an Entire Window 💀

if a whole window of data (or ACKs) gets lost, no ACKs come back to clock out more data. you can spot this when the last thing before a timeout was a data transmission triggered by an ACK ✨ losing a whole window forces recovery through a Retransmission Timeout and Slow-Start, period 😭

losing a full window means an outage that lasts at least one round trip time. that kind of outage can't be diagnosed with low rate metrics, and it's unsafe to diagnose at rates higher than the BTC 🙈 so all BTC metrics SHOULD instrument and report losses of an entire window of data 🌸

also, when you're running a very small window, there's a real chance the whole window gets wiped out by individual random losses, which is another reason cwnd instrumentation matters so much 💅

3.2.3 Heroic Clock Preservation 🦸‍♀️

any algorithm that lets a BTC keep its Self-Clock when other algorithms couldn't SHOULD be instrumented. and the details of those algorithms MUST be fully documented (as discussed in section 2) 📝 no skipping this part bestie 🫶

BTC metrics that can keep Self-Clock going through multiple losses within one round trip SHOULD instrument the loss distribution. that way, people can estimate how alternate congestion control algorithms (e.g., Reno style) would perform 👑

3.2.4 False Timeouts 🙈

false timeouts are when the retransmission timer goes off before the ACK for some previously sent data shows up. all of these SHOULD be instrumented when possible 🍓 heads up though, depending on how the BTC metric handles sequence numbers, this might be really hard to detect 😭

3.3 Ancillary Metrics Relating to Flow Based Path Properties 🎀

all BTC metrics give you a unique view of certain path properties involving closely spaced packets. just like with RTT duration outages, these can be impossible to diagnose at low rates (less than 1 packet per RTT), and it's inappropriate to test them at rates above the BTC of the network path 🫧

all BTC metrics SHOULD instrument packet reordering. the frequency and distance of out-of-sequence packets SHOULD be instrumented for all out-of-order packets 🌈 reordering severity falls into three cases, and each one SHOULD be reported 💖

• slightly out-of-order segments should not trigger the fast retransmit algorithm, but they may still affect the window calculation. BTC metrics SHOULD document how slightly out-of-order segments affect the congestion window calculation 🦋
• if segments are out-of-order enough, the Fast Retransmit algorithm gets invoked before the delayed packet's late arrival. these events SHOULD be instrumented 🔥 even though the late arriving packet finishes recovery, the window still gets cut in half 😤
• under some rare conditions, segments have shown up way 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 enough sender buffer space and receiver window (and window shift [RFC1323]) to cover that cwnd if it wants to expect the same performance 🧚

there are a bunch of other path properties you could measure inside a BTC metric too. for example, with an embedded one-way delay metric, you might be able to see how queuing delay and (RED) drop probabilities correlate with window size 🌸 these are open research questions, so the mystery is still very much alive ✨

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 dropped packets detected within the sending host MUST be reported 🚨 unless the sending interface is the path bottleneck, dropped packets probably mean the measurement failed 😭

the maximum queue lengths within the sending host SHOULD be instrumented. a big queue might mean the sending host doesn't have enough burst data rate and is smoothing out the data before it hits the network 🫧

3.5 Ancillary Metrics Relating to the Need for Advanced TCP Features 🌷

if TCP would need advanced TCP extensions to match BTC performance (like RFC 1323 or RFC 2018 features), that 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 that rely on non-cooperating receivers may only be able to measure round trip path properties, so they might not be able to tell the forward and reverse paths apart 🙃 in that case, the load the BTC metric puts on the reverse path SHOULD be instrumented (or computed) so other people can figure out what share of the round trip properties belongs to each direction 🧮

and 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, bestie 😳 this memo doesn't specify a particular implementation of a metric, so it doesn't directly affect the security of the Internet or the applications running on it. BUT metrics produced within this framework, and especially implementations of those metrics, may create security issues 🚨

4.1 Denial of Service Attacks 💀

Bulk Transport Capacity metrics, as defined in this document, naturally try to fill a bottleneck link 🌊 BTC metrics based on this specification will be as "network friendly" as current well-tuned TCP connections. however, since the "connection" might not be using TCP packets, a BTC test may look to network operators like a denial of service attack 😱

heads up: a BTC test running at full tilt can look exactly like an attack to the people watching the network, even when it's totally legit 🚨

administrators of the source host of a test, the destination host of a test, and the intervening network(s) may want to make bilateral or multi-lateral agreements about the timing, size, and frequency of collecting BTC metrics 🤝 communicate, babe 🫶

4.2 User data confidentiality 🔒

metrics in this framework generate packets for a sample, instead of taking samples from user data 💖 so a BTC metric does not threaten user data confidentiality ✨

4.3. Interference with metrics 🕵️‍♀️

Okay so bestie, it might be possible to spot that a certain packet, or a whole stream of packets, is part of a BTC metric. 👀 Once the destination or the networks in between know that, they can mess with how those packets get processed. Like, they could add or cut delay, or introduce loss or heroically prevent it, and that can totally distort the performance being measured. 😭 They could also generate extra packets that look like they belong to a BTC metric, and those fake packets are likely to perturb the sample measurement. Chaotic. 💀

To discourage this kind of interference, packet interference checks, such as a cryptographic hash, may be used. 🔐🫶

5. IANA Considerations 🎀

Since this metric framework doesn't define a specific protocol, and it doesn't define any well-known values either, there are no IANA considerations for this document. ✨ BUT, a bulk transport capacity metric inside this framework, and especially any protocols that actually implement a metric, might have IANA considerations that need to be addressed. So keep an eye out, babe. 👀

6. Acknowledgments 🫶

Huge thanks to Wil Leland, Jeff Semke, Matt Zekauskas, and the IPPM working group for all the numerous clarifications. 💖

Matt Mathis's work was supported by the National Science Foundation under Grant Numbers 9415552 and 9870758. 🌸

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.

[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.

[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

[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.

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

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. ✨