idnits 2.17.1 draft-ietf-ippm-btc-framework-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 565 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 2 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'Flo95' is defined on line 415, but no explicit reference was found in the text == Unused Reference: 'Hoe95' is defined on line 422, but no explicit reference was found in the text == Unused Reference: 'OKM96b' is defined on line 469, but no explicit reference was found in the text == Unused Reference: 'Pax97a' is defined on line 478, but no explicit reference was found in the text == Unused Reference: 'RFC793' is defined on line 488, but no explicit reference was found in the text == Unused Reference: 'RFC2001' is defined on line 501, but no explicit reference was found in the text == Unused Reference: 'RFC2018' is defined on line 505, but no explicit reference was found in the text == Unused Reference: 'RFC2525' is defined on line 528, but no explicit reference was found in the text == Unused Reference: 'Ste94' is defined on line 541, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FF96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Flo95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Hoe96' -- Possible downref: Non-RFC (?) normative reference: ref. 'Hoe95' -- Possible downref: Non-RFC (?) normative reference: ref. 'Jac88' -- Possible downref: Non-RFC (?) normative reference: ref. 'Lak94' -- Possible downref: Non-RFC (?) normative reference: ref. 'LK98' -- Possible downref: Non-RFC (?) normative reference: ref. 'LM97' -- Possible downref: Non-RFC (?) normative reference: ref. 'Mat98' -- Possible downref: Non-RFC (?) normative reference: ref. 'MM96a' -- Possible downref: Non-RFC (?) normative reference: ref. 'MM96b' -- Possible downref: Normative reference to a draft: ref. 'MSML99' -- Possible downref: Non-RFC (?) normative reference: ref. 'MSMO97' -- Possible downref: Non-RFC (?) normative reference: ref. 'OKM96a' -- Possible downref: Non-RFC (?) normative reference: ref. 'OKM96b' == Outdated reference: A later version (-01) exists of draft-paxson-tcp-rto-00 -- Possible downref: Non-RFC (?) normative reference: ref. 'Pax97a' -- Possible downref: Non-RFC (?) normative reference: ref. 'Pax97b' -- Possible downref: Non-RFC (?) normative reference: ref. 'PFTK98' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 1323 (Obsoleted by RFC 7323) ** Downref: Normative reference to an Informational RFC: RFC 1633 ** Obsolete normative reference: RFC 2001 (Obsoleted by RFC 2581) ** Downref: Normative reference to an Informational RFC: RFC 2216 ** Downref: Normative reference to an Informational RFC: RFC 2330 ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Obsolete normative reference: RFC 2481 (Obsoleted by RFC 3168) ** Downref: Normative reference to an Informational RFC: RFC 2525 ** Obsolete normative reference: RFC 2581 (Obsoleted by RFC 5681) ** Obsolete normative reference: RFC 2582 (Obsoleted by RFC 3782) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ste94' -- Possible downref: Non-RFC (?) normative reference: ref. 'WS95' Summary: 17 errors (**), 0 flaws (~~), 12 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Expires Apr. 2000 INTERNET-DRAFT 3 Network Working Group Matt Mathis 4 INTERNET-DRAFT Pittsburgh Supercomputing Center 5 Expiration Date: Apr. 2000 Mark Allman 6 NASA Glenn/BBN 7 October, 1999 9 Empirical Bulk Transfer Capacity 11 < draft-ietf-ippm-btc-framework-02.txt > 13 Status of this Document 15 This document is an Internet-Draft and is in full conformance with 16 all provisions of Section 10 of RFC2026. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as ``work in 27 progress.'' 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 Bulk Transport Capacity (BTC) is a measure of a network's ability to 38 transfer significant quantities of data with a single 39 congestion-aware transport connection (e.g., TCP). The intuitive 40 definition of BTC is the expected long term average data rate (bits 41 per second) of a single ideal TCP implementation over the path in 42 question. However, there are many congestion control algorithms 43 (and hence transport implementations) permitted by IETF standards. 44 This diversity in transport algorithms creates a difficulty for 45 standardizing BTC metrics because the allowed diversity is 46 sufficient to lead to situations where different implementations 47 will yield non-comparable measures -- and potentially fail the 48 formal tests for being a metric. 50 This document defines a framework for standardizing multiple BTC 51 metrics that parallel the permitted transport diversity. Two 52 approaches are used. First, each BTC metric must be much more 53 tightly specified than the typical IETF protocol. Pseudo-code or 54 reference implementations are expected to be the norm. Second, each 55 BTC methodology is expected to collect some ancillary metrics which 56 are potentially useful to support analytical models of BTC. 58 1. Introduction 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in [RFC2119]. Although 63 [RFC2119] was written with protocols in mind, the key words are used 64 in this document for similar reasons. They are used to ensure that 65 each BTC methodology defined contains specific pieces of 66 information. 68 Bulk Transport Capacity (BTC) is a measure of a network's ability to 69 transfer significant quantities of data with a single 70 congestion-aware transport connection (e.g., TCP). For many 71 applications the BTC of the underlying network dominates the overall 72 elapsed time for the application to run and thus dominates the 73 performance as perceived by a user. Examples of such applications 74 include FTP, and the world wide web when delivering large images or 75 documents. The intuitive definition of BTC is the expected long 76 term average data rate (bits per second) of a single ideal TCP 77 implementation over the path in question. 79 Central to the notion of bulk transport capacity is the idea that 80 all transport protocols should have similar responses to congestion 81 in the Internet. Indeed the only form of equity significantly 82 deployed in the Internet today is that the vast majority of all 83 traffic is carried by TCP implementations sharing common congestion 84 control algorithms largely due to a shared developmental heritage. 86 [RFC2581] specifies the standard congestion control algorithms used 87 by TCP implementations. Even though this document is a (proposed) 88 standard, it permits considerable latitude in implementation. This 89 latitude is by design, to encourage ongoing evolution in congestion 90 control algorithms. 92 This legal diversity in congestion control algorithms creates a 93 difficulty for standardizing BTC metrics because the allowed 94 diversity is sufficient to lead to situations where different 95 implementations will yield non-comparable measures -- and 96 potentially fail the formal tests for being a metric. 98 There is also evidence that most TCP implementations exhibit 99 non-linear performance over some portion of their operating region. 100 It is possible to construct simple simulation examples where 101 incremental improvements to a path (such as raising the link data 102 rate) results in lower overall TCP throughput (or BTC) [Mat98]. 104 We believe that such non-linearity reflects weakness in our current 105 understanding of congestion control and is present to some extent in 106 all TCP implementations and BTC metrics. Note that such 107 non-linearity (in either TCP or a BTC metric) is potentially 108 problematic in the market because investment in capacity might 109 actually reduce the perceived quality of the network. Ongoing 110 research in congestion dynamics has some hope of mitigating or 111 modeling the these non-linearities. 113 Furthermore related areas, including Integrated services 114 [RFC1633,RFC2216], differentiated services [RFC2475] and Internet 115 traffic analysis [MSMO97,PFTK98,Pax97b,LM97] are all currently 116 receiving significant attention from the research community. It is 117 likely that we will see new experimental congestion control 118 algorithms in the near future. In addition, Explicit Congestion 119 Notification (ECN) [RFC2481] is being tested for Internet 120 deployment. We do not yet know how any of these developments might 121 affect BTC metrics. 123 This document defines a framework for standardizing multiple BTC 124 metrics that parallel the permitted transport diversity. Two 125 approaches are used. First, each BTC metric must be much more 126 tightly specified than the typical IETF transport protocol. 127 Pseudo-code or reference implementations are expected to be the 128 norm. Second, each BTC methodology is expected to collect some 129 ancillary metrics which are potentially useful to support analytical 130 models of BTC. If a BTC methodology does not collect these 131 ancillary metrics, it should collect enough information such that 132 these metrics can be derived (for instance a segment trace file). 134 As an example, the models in [PFTK98, MSMO97, OKM96a, Lak94] all 135 predict bulk transfer performance based on path properties such as 136 loss rate and round trip time. A BTC methodology that also provides 137 ancillary measures of these properties is stronger because agreement 138 with the analytical models can be used to corroborate the direct BTC 139 measurement results. 141 More importantly the ancillary metrics are expected to be useful for 142 resolving disparity between different BTC methodologies. For 143 example, a path that predominantly experiences clustered packet 144 losses is likely to exhibit vastly different measures from BTC 145 metrics that mimic Tahoe, Reno, NewReno, and SACK TCP algorithms 146 [FF96]. The differences in the BTC metrics over such a path might 147 be diagnosed by an ancillary measure of loss clustering. 149 There are some path properties which are best measured as ancillary 150 metrics to a transport protocol. Examples of such properties 151 include bottleneck queue limits or the tendency to reorder packets. 152 These are difficult or impossible to measure at low rates and unsafe 153 to measure at rates higher than the bulk transport capacity of the 154 path. 156 It is expected that at some point in the future there will exist an 157 A-frame [RFC2330] which will unify all simple path metrics (e.g., 158 segment loss rates, round trip time) and BTC ancillary metrics 159 (e.g., queue size and packet reordering) with different versions of 160 BTC metrics (e.g., that parallel Reno or SACK TCP). 162 2. Congestion Control Algorithms 164 Nearly all TCP implementations in use today utilize the congestion 165 control algorithms published in [Jac88] and further refined in 166 [RFC2581]. In addition to using the basic notion of using an ACK 167 clock, TCP (and therefore BTC) implements five standard congestion 168 control algorithms: Congestion Avoidance, Retransmission timeouts, 169 Slow-start, Fast Retransmit and Fast Recovery. All BTC 170 implementations MUST implement slow start and congestion avoidance, 171 as specified in [RFC2581] (with extra details also specified, as 172 outlined below). All BTC methodologies SHOULD implement fast 173 retransmit and fast recovery as outlined in [RFC2581]. Finally, all 174 BTC methodologies MUST implement a retransmission timeout. 176 The algorithms specified in [RFC2581] give implementers some choices 177 in the details of the implementation. The following is a list of 178 details about the congestion control algorithms that are either 179 underspecified in [RFC2581] or very important to define when 180 constructing a BTC methodology. These details MUST be specifically 181 defined in each BTC methodology. 183 * [RFC2581] does not standardize a specific algorithm for 184 increasing cwnd during congestion avoidance. Several candidate 185 algorithms are given in [RFC2581]. 187 * [RFC2581] does not specify which cwnd increase algorithm (slow 188 start or congestion avoidance) should be used when cwnd equals 189 ssthresh. 191 * [RFC2581] allows TCPs to use advanced loss recovery mechanism 192 such as NewReno [RFC2582,FF96,Hoe96] and SACK-based algorithms 193 [FF96,MM96a,MM96b]. If used in a BTC implementation, such an 194 algorithm MUST be fully defined. 196 * The actual segment size, or method of choosing a segment size 197 (e.g., path MTU discovery [RFC1191]) and the number of header 198 bytes assumed to be prepended to each segment MUST be specified. 199 In addition, if the segment size is artificially limited to less 200 than the path MTU this MUST be indicated (if known). 202 * TCP includes a retransmission timeout (RTO) to trigger 203 retransmissions of segments that have not been acknowledged 204 within an appropriate amount of time and have not been 205 retransmitted via some more advanced loss recovery algorithm. A 206 BTC implementation MUST include a retransmission timer. 207 Calculating the RTO is subject to a number of details that MUST 208 be defined for each BTC metric. In addition, a BTC metric MUST 209 define when the clock is set and the granularity of the clock. 211 Note [WS95] outlines a popular implementation of the 212 retransmission timer. Also, a specification for the behavior of 213 the retransmission timer is currently being written for TCP 214 [PA99]. If adopted this specification would apply to BTC 215 implementation, as well. 217 3 Ancillary Metrics 219 The following ancillary metrics can provide additional information 220 about the network and the behavior of the implemented congestion 221 control algorithms in response to the behavior of the network path. 222 It is RECOMMENDED that these metrics be built into each BTC 223 methodology. Alternatively, it is RECOMMENDED that the BTC 224 implementation provide enough information such that the ancillary 225 metrics can be derived via post-processing (e.g., by providing a 226 segment trace of the connection). 228 3.1 Congestion Avoidance Capacity 230 The "Congestion Avoidance Capacity" (CAC) metric is the data rate 231 (bits per second) of a fully specified implementation of the 232 Congestion Avoidance algorithm, subject to the restriction that the 233 Retransmission Timeout and Slow-Start algorithms are not invoked. 234 The CAC metric is defined to have no meaning across Retransmission 235 Timeouts or Slow-Start periods (except the single segment Slow-Start 236 that is permitted to follow recovery, as discussed in section 2.3). 238 In principle a CAC metric would be an ideal BTC metric, as it 239 captures what should be TCP's steady state behavior. But, there is 240 a rather substantial difficulty with using it as such. The 241 Self-Clocking of the Congestion Avoidance algorithm can be very 242 fragile, depending on the specific details of the Fast Retransmit, 243 Fast Recovery or advanced recovery algorithms above. It has been 244 found that timeouts and periods of slow start loss recovery are 245 prevalent in traffic on the Internet [LK98] and therefore these 246 should be captured by the BTC metric. 248 When TCP loses Self-Clock it is re-established through a 249 retransmission timeout and Slow-Start. These algorithms nearly 250 always require more time than Congestion Avoidance would have taken. 251 It is easily observed that unless the network loses an entire window 252 of data (which would clearly require a retransmit timeout) TCP 253 missed some opportunity to safely transmit data. That is, if TCP 254 experiences a timeout after losing a partial window of data, it must 255 have received at least one ACK that was generated after some of the 256 partial data was delivered, but did not trigger the transmission of 257 new data. Recent research in congestion control (e.g., FACK 258 [MM96a], NewReno [FF96,RFC2582], rate-halving [MSML99]) can be 259 characterized as making TCP's Self-Clock more tenacious, while 260 preserving fairness under adverse conditions. This work is 261 motivated by how poorly current TCP implementations perform under 262 some conditions, often due to repeated clock loss. Since this is an 263 active research area, different TCP implementations have rather 264 considerable differences in their ability to preserve Self-Clock. 266 3.2 Preservation of Self-Clock 268 Losing the ACK clock can have a large effect on the overall BTC, and 269 the clock is itself fragile in ways that are dependent on the loss 270 recovery algorithm. Therefore, the transition between timer driven 271 and Self-Clocked operation SHOULD be instrumented. 273 3.2.1 Lost Transmission Opportunities 275 If the last event before a timeout was the receipt of an ACK that 276 did not trigger a transmission, the possibility exists that an 277 alternate congestion control algorithm would have successfully 278 preserved the Self-Clock. A BTC SHOULD instrument key items in the 279 BTC state (such as the congestion window) in the hopes that this may 280 lead to further improvements in congestion control algorithms. 282 Note that in the absence of knowledge about the future, it is not 283 possible to design an algorithm that never misses transmission 284 opportunities. However, there are ever more subtle ways to gauge 285 network state, and to estimate if a given ACK is likely to be the 286 last. 288 3.2.2 Loosing an Entire Window 290 If an entire window of data (or ACKs) is lost, there will be no 291 returning ACKs to clock out additional data. This condition can 292 be detected if the last event before a timeout was a data 293 transmission triggered by an ACK. The loss of an entire window 294 of data/ACKs forces recovery to be via a Retransmission Timeout and 295 Slow-Start. 297 Losing an entire window of data implies an outage with a duration at 298 least as long as a round trip time. Such an outage can not be 299 diagnosed with low rate metrics and is unsafe to diagnose at higher 300 rates than the BTC. Therefore all BTC metrics SHOULD instrument and 301 report losses of an entire window of data. 303 Note that there are some conditions, such as when operating with a 304 very small window, in which there is a significant probability that 305 an entire window can be lost through individual random losses (again 306 highlighting the importance of instrumenting cwnd). 308 3.2.3 Heroic Clock Preservation 310 All algorithms that permit a given BTC to sustain Self-Clock when 311 other algorithms might not, SHOULD be instrumented. Furthermore, 312 the details of the algorithms used MUST be fully documented (as 313 discussed in section 2). 315 BTC metrics that can sustain Self-Clock in the presence of multiple 316 losses within one round trip SHOULD instrument the loss 317 distribution, such that the performance of alternate congestion 318 control algorithms may be estimated (e.g., Reno style). 320 3.2.4 False Timeouts 322 All false timeouts, (where the retransmission timer expires before 323 the ACK for some previously transmitted data arrives) SHOULD be 324 instrumented when possible. Note that depending upon how the BTC 325 metric implements sequence numbers, this may be difficult to detect. 327 3.3 Ancillary Metrics Relating to Flow Based Path Properties 329 All BTC metrics provide unique vantage points for observing certain 330 path properties relating to closely spaced packets. As in the case 331 of RTT duration outages, these can be impossible to diagnose at low 332 rates (less than 1 packet per RTT) and inappropriate to test at 333 rates above the BTC of the network path. 335 All BTC metrics SHOULD instrument packet reordering. The frequency 336 and distance out-of-sequence SHOULD be instrumented for all 337 out-of-order packets. The severity of the reordering can be 338 classified as one of three different cases, each of which SHOULD be 339 reported. 341 Packets that are only slightly out-of-order should not trigger 342 the fast retransmit algorithm, but they may affect the window 343 calculation. BTC metrics SHOULD document how slightly 344 out-of-order packets affect the congestion window calculation. 346 If packets are sufficiently out-of-order, the Fast Retransmit 347 algorithm will be invoked in advance of the delayed packet's 348 late arrival. These events SHOULD be instrumented. Even though 349 the the late arriving packet will complete recovery, the the 350 window will still be reduced by half. 352 Under some rare conditions packets have been observed that are 353 far out of order - sometimes many seconds late [Pax97b]. These 354 SHOULD always be instrumented. 356 BTC implementations SHOULD instrument the maximum cwnd observed 357 during congestion avoidance and slow start. A TCP running over the 358 same path as the BTC metric must have sufficient sender buffer space 359 and receiver window (and window shift [RFC1323]) to cover this cwnd 360 in order to expect the same performance. 362 There are several other path properties that one might measure 363 within a BTC metric. For example, with an embedded one-way delay 364 metric it may be possible to measure how queueing delay and and 365 (RED) drop probabilities are correlated to window size. These are 366 open research questions. 368 3.4 Ancillary Metrics as Calibration Checks 370 Unlike low rate metrics, BTC SHOULD include explicit checks that the 371 test platform is not the bottleneck. 373 Any detected dropped packets within the sending host MUST be reported. 374 Unless the sending interface is the path bottleneck, any dropped 375 packets probably indicates a measurement failure. 377 The maximum queue lengths within the sending host SHOULD be 378 instrumented. Any significant queue may indicate that the sending 379 host has insufficient burst data rate, and is smoothing the data 380 being transmitted into the network. 382 3.5 Ancillary Metrics Relating to the Need for Advanced TCP Features 384 If TCP would require advanced TCP extensions to match BTC 385 performance (such as RFC 1323 or RFC 2018 features), it SHOULD be 386 reported. 388 3.6 Validate Reverse Path Load 390 To the extent possible, the BTC metric SHOULD distinguish between 391 the properties of the forward and reverse paths. 393 BTC methodologies which rely on non-cooperating receivers may only 394 be able to measure round trip path properties and may not be able to 395 independently differentiate between the properties of the forward 396 and reverse paths. In this case the load on the reverse path 397 contributed by the BTC metric SHOULD be instrumented (or computed) 398 to permit other means of gage the proportion of the round trip path 399 properties attributed to the the forward and reverse paths. 401 To the extent possible, BTC methodologies that rely on cooperating 402 receivers SHOULD support separate ancillary metrics for the forward 403 and reverse paths. 405 4 Acknowledgments 407 Thanks to Jeff Semke for numerous clarifications. 409 5 References 411 [FF96] Fall, K., Floyd, S.. "Simulation-based Comparisons of Tahoe, 412 Reno and SACK TCP". Computer Communication Review, July 1996. 413 ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z. 415 [Flo95] Floyd, S., "TCP and successive fast retransmits", March 416 1995, Obtain via ftp://ftp.ee.lbl.gov/papers/fastretrans.ps. 418 [Hoe96] Hoe, J., "Improving the start-up behavior of a congestion 419 control scheme for TCP, Proceedings of ACM SIGCOMM '96, August 420 1996. 422 [Hoe95] Hoe, J., "Startup dynamics of TCP's congestion control and 423 avoidance schemes". Master's thesis, Massachusetts Institute of 424 Technology, June 1995. 426 [Jac88] Jacobson, V., "Congestion Avoidance and Control", 427 Proceedings of SIGCOMM '88, Stanford, CA., August 1988. 429 [Lak94] Lakshman, Effects of random loss 431 [LK98] Lin, D. and Kung, H.T., "TCP Fast Recovery Strategies: 432 Analysis and Improvements", Proceedings of InfoCom, March 1998. 434 [LM97] T.V.Lakshman and U.Madhow. "The Performance of TCP/IP for 435 Networks with High Bandwidth-Delay Products and Random Loss". 436 IEEE/ACM Transactions on Networking, Vol. 5, No. 3, June 1997, 437 pp.336-350. 439 [Mat98] Mathis, M., "Empirical Bulk Transfer Capacity", IP 440 Performance Metrics Working Group report in Proceedings of the 441 Forty Third Internet Engineering Task Force, Orlando, FL, 442 December 1988. Available from 443 http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-122.html 444 and 445 http://www.ietf.org/proceedings/98dec/slides/ippm-mathis-98dec.pdf. 447 [MM96a] Mathis, M. and Mahdavi, J. "Forward acknowledgment: Refining 448 TCP congestion control", Proceedings of ACM SIGCOMM '96, 449 Stanford, CA., August 1996. 451 [MM96b] M. Mathis, J. Mahdavi, "TCP Rate-Halving with Bounding 452 Parameters" Available from 453 http://www.psc.edu/networking/papers/FACKnotes/current. 455 [MSML99] Mathis, M., Semke, J., Mahdavi, J., Lahey, K., "The 456 Rate-Halving Algorithm for TCP Congestion Control", June 1999. 457 Internet-Draft draft-mathis-tcp-ratehalving-00.txt (work in 458 progress). 460 [MSMO97] Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The 461 Macroscopic Behavior of the TCP Congestion Avoidance Algorithm", 462 Computer Communications Review, 27(3), July 1997. 464 [OKM96a], Ott, T., Kemperman, J., Mathis, M., "The Stationary 465 Behavior of Ideal TCP Congestion Avoidance", In progress, August 466 1996. Obtain via pub/tjo/TCPwindow.ps using anonymous ftp to 467 ftp.bellcore.com 469 [OKM96b], Ott, T., Kemperman, J., Mathis, M., "Window Size Behavior 470 in TCP/IP with Constant Loss Probability", DIMACS Special Year 471 on Networks, Workshop on Performance of Real-Time Applications 472 on the Internet, Nov 1996. 474 [PA99] Paxson, V., Allman, M., "Computing TCP's Retransmission 475 Timer", October 1999. Internet-Draft draft-paxson-tcp-rto-00.txt 476 (work in progress). 478 [Pax97a] Paxson, V., "Automated Packet Trace Analysis of TCP 479 Implementations", Proceedings of ACM SIGCOMM '97, August 1997. 481 [Pax97b] Paxson, V., "End-to-End Internet Packet Dynamics," 482 Proceedings of SIGCOMM '97, Cannes, France, Sep. 1997. 484 [PFTK98] Padhye, J., Firoiu. V., Towsley, D., and Kurose, J., "TCP 485 Throughput: A Simple Model and its Empirical Validation", 486 Proceedings of ACM SIGCOMM '98, August 1998. 488 [RFC793] Postel, J., "Transmission Control Protocol", 1981, Obtain 489 via: ftp://ds.internic.net/rfc/rfc793.txt 491 [RFC1191] Mogul, J., Deering, S., "Path MTU Discovery", November 492 1990, Obtain via: ftp://ds.internic.net/rfc/rfc1191.txt 494 [RFC1323] Jacobson, V., Braden, R., Borman, D., "TCP Extensions for 495 High Performance", May 1992, Obtain via: 496 ftp://ds.internic.net/rfc/rfc1323.txt 498 [RFC1633] Braden R., Clark D., Shenker S., "Integrated Services in 499 the Internet Architecture: an Overview"., 1994. 501 [RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast 502 Retransmit, and Fast Recovery Algorithms", 1997, Obtain via: 503 ftp://ds.internic.net/rfc/rfc2001.txt 505 [RFC2018] Mathis, M., Mahdavi, J. Floyd, S., Romanow, A., "TCP 506 Selective Acknowledgment Options", 1996, Obtain via: 507 ftp://ds.internic.net/rfc/rfc2018.txt 509 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 510 Requirement Levels", 1997, Obtain via: 511 ftp://ds.internic.net/rfc/rfc2119.txt 513 [RFC2216] Shenker, S., Wroclawski, J., "Network Element Service 514 Specification Template", 1997, Obtain via: 515 ftp://ds.internic.net/rfc/rfc2216.txt 517 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., Mathis, M., "Framework 518 for IP Performance Metrics" , 1998, Obtain via: 519 ftp://ds.internic.net/rfc/rfc2330.txt 521 [RFC2475] Black D., Blake S., Carlson M., Davies E., Wang Z., Weiss 522 W., "An Architecture for Differentiated Services"., 1998. 524 [RFC2481] K. Ramakrishnan, S. Floyd, "A Proposal to add Explicit 525 Congestion Notification (ECN) to IP", 1999, Obtain via: 526 ftp://ds.internic.net/rfc/rfc2481.txt 528 [RFC2525] V. Paxson, M. Allman, S. Dawson, W. Fenner, J. Griner, 529 I. Heavens, K. Lahey, J. Semke, B. Volz, "Known TCP 530 Implementation Problems", 1999, Obtain via: 531 ftp://ds.internic.net/rfc/rfc2525.txt 533 [RFC2581] Allman, M., Paxson, V., Stevens, W., "TCP Congestion 534 Control"., 1999, Obtain via: 535 ftp://ds.internic.net/rfc/rfc2581.txt 537 [RFC2582] Floyd, S., Henderson, T., "The NewReno Modification to 538 TCP's Fast Recovery Algorithm", 1999, Obtain via: 539 ftp://ds.internic.net/rfc/rfc2582.txt 541 [Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols", 542 Addison-Wesley, 1994. 544 [WS95] Wright, G., Stevens, W., "TCP/IP Illustrated Volume II: The 545 Implementation", Addison-Wesley, 1995. 547 Author's Addresses 549 Matt Mathis 550 Pittsburgh Supercomputing Center 551 4400 Fifth Ave. 552 Pittsburgh PA 15213 553 mathis@psc.edu 554 http://www.psc.edu/~mathis 556 Mark Allman 557 NASA Glenn Research Center/BBN Technologies 558 Lewis Field 559 21000 Brookpark Rd. MS 54-2 560 Cleveland, OH 44135 561 216-433-6586 562 mallman@grc.nasa.gov 563 http://roland.grc.nasa.gov/~mallman