idnits 2.17.1 draft-ietf-ippm-btc-framework-04.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 598 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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 5 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. 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 448, but no explicit reference was found in the text == Unused Reference: 'Hoe95' is defined on line 455, but no explicit reference was found in the text == Unused Reference: 'LK98' is defined on line 464, but no explicit reference was found in the text == Unused Reference: 'OKM96b' is defined on line 502, but no explicit reference was found in the text == Unused Reference: 'Pax97a' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'RFC793' is defined on line 517, but no explicit reference was found in the text == Unused Reference: 'RFC2001' is defined on line 530, but no explicit reference was found in the text == Unused Reference: 'RFC2018' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'RFC2525' is defined on line 557, but no explicit reference was found in the text == Unused Reference: 'Ste94' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'WS95' is defined on line 577, 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' -- 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) ** Obsolete normative reference: RFC 2988 (Obsoleted by RFC 6298) -- Possible downref: Non-RFC (?) normative reference: ref. 'Ste94' -- Possible downref: Non-RFC (?) normative reference: ref. 'WS95' Summary: 18 errors (**), 0 flaws (~~), 13 warnings (==), 22 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Expires May 2001 INTERNET-DRAFT 3 Network Working Group Matt Mathis 4 INTERNET-DRAFT Pittsburgh Supercomputing Center 5 Expiration Date: May 2001 Mark Allman 6 NASA Glenn/BBN 7 December, 2000 9 A Framework for Defining Empirical Bulk Transfer Capacity Metrics 11 < draft-ietf-ippm-btc-framework-04.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. The specific definition 78 of the bulk transfer capacity that MUST be reported by a BTC tool is: 80 BTC = data_sent / elapsed_time 82 where ``data_sent'' represents the unique ``data'' bytes transfered 83 (i.e., not including header bytes or emulated header bytes). Also 84 note that the amount of data sent should only include the unique 85 number of bytes transmitted (i.e., if a particular packet is 86 retransmitted the data it contains should be counted only once). 88 Central to the notion of bulk transport capacity is the idea that 89 all transport protocols should have similar responses to congestion 90 in the Internet. Indeed the only form of equity significantly 91 deployed in the Internet today is that the vast majority of all 92 traffic is carried by TCP implementations sharing common congestion 93 control algorithms largely due to a shared developmental heritage. 95 [RFC2581] specifies the standard congestion control algorithms used 96 by TCP implementations. Even though this document is a (proposed) 97 standard, it permits considerable latitude in implementation. This 98 latitude is by design, to encourage ongoing evolution in congestion 99 control algorithms. 101 This legal diversity in congestion control algorithms creates a 102 difficulty for standardizing BTC metrics because the allowed 103 diversity is sufficient to lead to situations where different 104 implementations will yield non-comparable measures -- and 105 potentially fail the formal tests for being a metric. 107 There is also evidence that most TCP implementations exhibit 108 non-linear performance over some portion of their operating region. 109 It is possible to construct simple simulation examples where 110 incremental improvements to a path (such as raising the link data 111 rate) results in lower overall TCP throughput (or BTC) [Mat98]. 113 We believe that such non-linearity reflects weakness in our current 114 understanding of congestion control and is present to some extent in 115 all TCP implementations and BTC metrics. Note that such 116 non-linearity (in either TCP or a BTC metric) is potentially 117 problematic in the market because investment in capacity might 118 actually reduce the perceived quality of the network. Ongoing 119 research in congestion dynamics has some hope of mitigating or 120 modeling the these non-linearities. 122 Related areas, including Integrated services 123 [RFC1633,RFC2216], differentiated services [RFC2475] and Internet 124 traffic analysis [MSMO97,PFTK98,Pax97b,LM97] are all currently 125 receiving significant attention from the research community. It is 126 likely that we will see new experimental congestion control 127 algorithms in the near future. In addition, Explicit Congestion 128 Notification (ECN) [RFC2481] is being tested for Internet 129 deployment. We do not yet know how any of these developments might 130 affect BTC metrics, and thus the BTC framework and metrics may need 131 to be revisited in the future. 133 This document defines a framework for standardizing multiple BTC 134 metrics that parallel the permitted transport diversity. Two 135 approaches are used. First, each BTC metric must be much more 136 tightly specified than the typical IETF transport protocol. 137 Pseudo-code or reference implementations are expected to be the 138 norm. Second, each BTC methodology is expected to collect some 139 ancillary metrics which are potentially useful to support analytical 140 models of BTC. If a BTC methodology does not collect these 141 ancillary metrics, it should collect enough information such that 142 these metrics can be derived (for instance a segment trace file). 144 As an example, the models in [PFTK98, MSMO97, OKM96a, Lak94] all 145 predict bulk transfer performance based on path properties such as 146 loss rate and round trip time. A BTC methodology that also provides 147 ancillary measures of these properties is stronger because agreement 148 with the analytical models can be used to corroborate the direct BTC 149 measurement results. 151 More importantly the ancillary metrics are expected to be useful for 152 resolving disparity between different BTC methodologies. For 153 example, a path that predominantly experiences clustered packet 154 losses is likely to exhibit vastly different measures from BTC 155 metrics that mimic Tahoe, Reno, NewReno, and SACK TCP algorithms 156 [FF96]. The differences in the BTC metrics over such a path might 157 be diagnosed by an ancillary measure of loss clustering. 159 There are some path properties which are best measured as ancillary 160 metrics to a transport protocol. Examples of such properties 161 include bottleneck queue limits or the tendency to reorder packets. 162 These are difficult or impossible to measure at low rates and unsafe 163 to measure at rates higher than the bulk transport capacity of the 164 path. 166 It is expected that at some point in the future there will exist an 167 A-frame [RFC2330] which will unify all simple path metrics (e.g., 168 segment loss rates, round trip time) and BTC ancillary metrics 169 (e.g., queue size and packet reordering) with different versions of 170 BTC metrics (e.g., that parallel Reno or SACK TCP). 172 2 Congestion Control Algorithms 174 Nearly all TCP implementations in use today utilize the congestion 175 control algorithms published in [Jac88] and further refined in 176 [RFC2581]. In addition to using the basic notion of using an ACK 177 clock, TCP (and therefore BTC) implements five standard congestion 178 control algorithms: Congestion Avoidance, Retransmission timeouts, 179 Slow-start, Fast Retransmit and Fast Recovery. All BTC 180 implementations MUST implement slow start and congestion avoidance, 181 as specified in [RFC2581] (with extra details also specified, as 182 outlined below). All BTC methodologies SHOULD implement fast 183 retransmit and fast recovery as outlined in [RFC2581]. Finally, all 184 BTC methodologies MUST implement a retransmission timeout. 186 The algorithms specified in [RFC2581] give implementers some choices 187 in the details of the implementation. The following is a list of 188 details about the congestion control algorithms that are either 189 underspecified in [RFC2581] or very important to define when 190 constructing a BTC methodology. These details MUST be specifically 191 defined in each BTC methodology. 193 * [RFC2581] does not standardize a specific algorithm for 194 increasing cwnd during congestion avoidance. Several candidate 195 algorithms are given in [RFC2581]. 197 * [RFC2581] does not specify which cwnd increase algorithm (slow 198 start or congestion avoidance) should be used when cwnd equals 199 ssthresh. 201 * [RFC2581] allows TCPs to use advanced loss recovery mechanism 202 such as NewReno [RFC2582,FF96,Hoe96] and SACK-based algorithms 203 [FF96,MM96a,MM96b]. If used in a BTC implementation, such an 204 algorithm MUST be fully defined. 206 * The actual segment size, or method of choosing a segment size 207 (e.g., path MTU discovery [RFC1191]) and the number of header 208 bytes assumed to be prepended to each segment MUST be specified. 209 In addition, if the segment size is artificially limited to less 210 than the path MTU this MUST be indicated. 212 * TCP includes a retransmission timeout (RTO) to trigger 213 retransmissions of segments that have not been acknowledged 214 within an appropriate amount of time and have not been 215 retransmitted via some more advanced loss recovery algorithm. A 216 BTC implementation MUST include a retransmission timer. 217 Calculating the RTO is subject to a number of details that MUST 218 be defined for each BTC metric. In addition, a BTC metric MUST 219 define when the clock is set and the granularity of the clock. 221 [RFC2988] specifies the behavior of the retransmission timer. 222 However, there are several details left to the implementer which 223 MUST be specified for each BTC metric defined. 225 Note that as new congestion control algorithms are placed on the 226 standards track they may be incorporated into BTC metrics (e.g., the 227 Limited Transmit algorithm [ABF00]). However, any implementation 228 decisions provided by the relevant RFCs should be fully specified in 229 the particular BTC metric. 231 3 Ancillary Metrics 233 The following ancillary metrics can provide additional information 234 about the network and the behavior of the implemented congestion 235 control algorithms in response to the behavior of the network path. 236 It is RECOMMENDED that these metrics be built into each BTC 237 methodology. Alternatively, it is RECOMMENDED that the BTC 238 implementation provide enough information such that the ancillary 239 metrics can be derived via post-processing (e.g., by providing a 240 segment trace of the connection). 242 3.1 Congestion Avoidance Capacity 244 The "Congestion Avoidance Capacity" (CAC) metric is the data rate 245 (bits per second) of a fully specified implementation of the 246 Congestion Avoidance algorithm, subject to the restriction that the 247 Retransmission Timeout and Slow-Start algorithms are not invoked. 248 The CAC metric is defined to have no meaning across Retransmission 249 Timeouts or Slow-Start periods (except the single segment Slow-Start 250 that is permitted to follow recovery, as discussed in section 2.3). 252 In principle a CAC metric would be an ideal BTC metric, as it 253 captures what should be TCP's steady state behavior. But, there is 254 a rather substantial difficulty with using it as such. The 255 Self-Clocking of the Congestion Avoidance algorithm can be very 256 fragile, depending on the specific details of the Fast Retransmit, 257 Fast Recovery or advanced recovery algorithms chosen. It has been 258 found that timeouts and periods of slow start loss recovery are 259 prevalent in traffic on the Internet [LK98,BPS+97] and therefore these 260 should be captured by the BTC metric. 262 When TCP loses Self-Clock it is re-established through a 263 retransmission timeout and Slow-Start. These algorithms nearly 264 always require more time than Congestion Avoidance would have taken. 265 It is easily observed that unless the network loses an entire window 266 of data (which would clearly require a retransmit timeout) TCP 267 likely missed some opportunity to safely transmit data. That is, if TCP 268 experiences a timeout after losing a partial window of data, it must 269 have received at least one ACK that was generated after some of the 270 partial data was delivered, but did not trigger the transmission of 271 new data. Recent research in congestion control (e.g., FACK 272 [MM96a], NewReno [FF96,RFC2582], rate-halving [MSML99]) can be 273 characterized as making TCP's Self-Clock more tenacious, while 274 preserving fairness under adverse conditions. This work is 275 motivated by how poorly current TCP implementations perform under 276 some conditions, often due to repeated clock loss. Since this is an 277 active research area, different TCP implementations have rather 278 considerable differences in their ability to preserve Self-Clock. 280 3.2 Preservation of Self-Clock 282 Losing the ACK clock can have a large effect on the overall BTC, and 283 the clock is itself fragile in ways that are dependent on the loss 284 recovery algorithm. Therefore, the transition between timer driven 285 and Self-Clocked operation SHOULD be instrumented. 287 3.2.1 Lost Transmission Opportunities 289 If the last event before a timeout was the receipt of an ACK that 290 did not trigger a transmission, the possibility exists that an 291 alternate congestion control algorithm would have successfully 292 preserved the Self-Clock. A BTC SHOULD instrument key items in the 293 BTC state (such as the congestion window) in the hopes that this may 294 lead to further improvements in congestion control algorithms. 296 Note that in the absence of knowledge about the future, it is not 297 possible to design an algorithm that never misses transmission 298 opportunities. However, there are ever more subtle ways to gauge 299 network state, and to estimate if a given ACK is likely to be the 300 last. 302 3.2.2 Loosing an Entire Window 304 If an entire window of data (or ACKs) is lost, there will be no 305 returning ACKs to clock out additional data. This condition can 306 be detected if the last event before a timeout was a data 307 transmission triggered by an ACK. The loss of an entire window 308 of data/ACKs forces recovery to be via a Retransmission Timeout and 309 Slow-Start. 311 Losing an entire window of data implies an outage with a duration at 312 least as long as a round trip time. Such an outage can not be 313 diagnosed with low rate metrics and is unsafe to diagnose at higher 314 rates than the BTC. Therefore all BTC metrics SHOULD instrument and 315 report losses of an entire window of data. 317 Note that there are some conditions, such as when operating with a 318 very small window, in which there is a significant probability that 319 an entire window can be lost through individual random losses (again 320 highlighting the importance of instrumenting cwnd). 322 3.2.3 Heroic Clock Preservation 324 All algorithms that permit a given BTC to sustain Self-Clock when 325 other algorithms might not, SHOULD be instrumented. Furthermore, 326 the details of the algorithms used MUST be fully documented (as 327 discussed in section 2). 329 BTC metrics that can sustain Self-Clock in the presence of multiple 330 losses within one round trip SHOULD instrument the loss 331 distribution, such that the performance of alternate congestion 332 control algorithms may be estimated (e.g., Reno style). 334 3.2.4 False Timeouts 336 All false timeouts, (where the retransmission timer expires before 337 the ACK for some previously transmitted data arrives) SHOULD be 338 instrumented when possible. Note that depending upon how the BTC 339 metric implements sequence numbers, this may be difficult to detect. 341 3.3 Ancillary Metrics Relating to Flow Based Path Properties 343 All BTC metrics provide unique vantage points for observing certain 344 path properties relating to closely spaced packets. As in the case 345 of RTT duration outages, these can be impossible to diagnose at low 346 rates (less than 1 packet per RTT) and inappropriate to test at 347 rates above the BTC of the network path. 349 All BTC metrics SHOULD instrument packet reordering. The frequency 350 and distance out-of-sequence SHOULD be instrumented for all 351 out-of-order packets. The severity of the reordering can be 352 classified as one of three different cases, each of which SHOULD be 353 reported. 355 Segments that are only slightly out-of-order should not trigger 356 the fast retransmit algorithm, but they may affect the window 357 calculation. BTC metrics SHOULD document how slightly 358 out-of-order segments affect the congestion window calculation. 360 If segments are sufficiently out-of-order, the Fast Retransmit 361 algorithm will be invoked in advance of the delayed packet's 362 late arrival. These events SHOULD be instrumented. Even though 363 the the late arriving packet will complete recovery, the the 364 window will still be reduced by half. 366 Under some rare conditions segments have been observed that are 367 far out of order - sometimes many seconds late [Pax97b]. These 368 SHOULD always be instrumented. 370 BTC implementations SHOULD instrument the maximum cwnd observed 371 during congestion avoidance and slow start. A TCP running over the 372 same path as the BTC metric must have sufficient sender buffer space 373 and receiver window (and window shift [RFC1323]) to cover this cwnd 374 in order to expect the same performance. 376 There are several other path properties that one might measure 377 within a BTC metric. For example, with an embedded one-way delay 378 metric it may be possible to measure how queueing delay and and 379 (RED) drop probabilities are correlated to window size. These are 380 open research questions. 382 3.4 Ancillary Metrics as Calibration Checks 384 Unlike low rate metrics, BTC SHOULD include explicit checks that the 385 test platform is not the bottleneck. 387 Any detected dropped packets within the sending host MUST be reported. 388 Unless the sending interface is the path bottleneck, any dropped 389 packets probably indicates a measurement failure. 391 The maximum queue lengths within the sending host SHOULD be 392 instrumented. Any significant queue may indicate that the sending 393 host has insufficient burst data rate, and is smoothing the data 394 being transmitted into the network. 396 3.5 Ancillary Metrics Relating to the Need for Advanced TCP Features 398 If TCP would require advanced TCP extensions to match BTC 399 performance (such as RFC 1323 or RFC 2018 features), it SHOULD be 400 reported. 402 3.6 Validate Reverse Path Load 404 To the extent possible, the BTC metric SHOULD distinguish between 405 the properties of the forward and reverse paths. 407 BTC methodologies which rely on non-cooperating receivers may only 408 be able to measure round trip path properties and may not be able to 409 independently differentiate between the properties of the forward 410 and reverse paths. In this case the load on the reverse path 411 contributed by the BTC metric SHOULD be instrumented (or computed) 412 to permit other means of gauge the proportion of the round trip path 413 properties attributed to the the forward and reverse paths. 415 To the extent possible, BTC methodologies that rely on cooperating 416 receivers SHOULD support separate ancillary metrics for the forward 417 and reverse paths. 419 4 Security Considerations 421 The framework for specifying BTC metrics outlined in this document 422 does not pose any threat to Internet security. The BTC metrics 423 defined based on this specification will be as ``network friendly'' 424 as current TCP connections. 426 5 Acknowledgments 428 Thanks to Jeff Semke for numerous clarifications. 430 6 References 432 [ABF00] Mark Allman, Hari Balakrishnan, Sally Floyd. Enhancing 433 TCP's Loss Recovery Using Limited Transmit, August 434 2000. Internet-Draft draft-ietf-tsvwg-limited-xmit-00.txt (work 435 in progress). 437 [BPS+97] Hari Balakrishnan, Venkata Padmanabhan, Srinivasan Seshan, 438 Mark Stemm, and Randy Katz. TCP Behavior of a Busy Web Server: 439 Analysis and Improvements. Technical Report UCB/CSD-97-966, 440 August 1997. Available from 441 http://nms.lcs.mit.edu/~hari/papers/csd-97-966.ps. (Also in 442 Proc. IEEE INFOCOM Conf., San Francisco, CA, March 1998.) 444 [FF96] Fall, K., Floyd, S.. "Simulation-based Comparisons of Tahoe, 445 Reno and SACK TCP". Computer Communication Review, July 1996. 446 ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z. 448 [Flo95] Floyd, S., "TCP and successive fast retransmits", March 449 1995, Obtain via ftp://ftp.ee.lbl.gov/papers/fastretrans.ps. 451 [Hoe96] Hoe, J., "Improving the start-up behavior of a congestion 452 control scheme for TCP, Proceedings of ACM SIGCOMM '96, August 453 1996. 455 [Hoe95] Hoe, J., "Startup dynamics of TCP's congestion control and 456 avoidance schemes". Master's thesis, Massachusetts Institute of 457 Technology, June 1995. 459 [Jac88] Jacobson, V., "Congestion Avoidance and Control", 460 Proceedings of SIGCOMM '88, Stanford, CA., August 1988. 462 [Lak94] Lakshman, Effects of random loss 464 [LK98] Lin, D. and Kung, H.T., "TCP Fast Recovery Strategies: 465 Analysis and Improvements", Proceedings of InfoCom, March 1998. 467 [LM97] T.V.Lakshman and U.Madhow. "The Performance of TCP/IP for 468 Networks with High Bandwidth-Delay Products and Random Loss". 469 IEEE/ACM Transactions on Networking, Vol. 5, No. 3, June 1997, 470 pp.336-350. 472 [Mat98] Mathis, M., "Empirical Bulk Transfer Capacity", IP 473 Performance Metrics Working Group report in Proceedings of the 474 Forty Third Internet Engineering Task Force, Orlando, FL, 475 December 1988. Available from 476 http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-122.html 477 and 478 http://www.ietf.org/proceedings/98dec/slides/ippm-mathis-98dec.pdf. 480 [MM96a] Mathis, M. and Mahdavi, J. "Forward acknowledgment: Refining 481 TCP congestion control", Proceedings of ACM SIGCOMM '96, 482 Stanford, CA., August 1996. 484 [MM96b] M. Mathis, J. Mahdavi, "TCP Rate-Halving with Bounding 485 Parameters" Available from 486 http://www.psc.edu/networking/papers/FACKnotes/current. 488 [MSML99] Mathis, M., Semke, J., Mahdavi, J., Lahey, K., "The 489 Rate-Halving Algorithm for TCP Congestion Control", June 1999. 490 Internet-Draft draft-mathis-tcp-ratehalving-00.txt (work in 491 progress). 493 [MSMO97] Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The 494 Macroscopic Behavior of the TCP Congestion Avoidance Algorithm", 495 Computer Communications Review, 27(3), July 1997. 497 [OKM96a], Ott, T., Kemperman, J., Mathis, M., "The Stationary 498 Behavior of Ideal TCP Congestion Avoidance", In progress, August 499 1996. Obtain via pub/tjo/TCPwindow.ps using anonymous ftp to 500 ftp.bellcore.com 502 [OKM96b], Ott, T., Kemperman, J., Mathis, M., "Window Size Behavior 503 in TCP/IP with Constant Loss Probability", DIMACS Special Year 504 on Networks, Workshop on Performance of Real-Time Applications 505 on the Internet, Nov 1996. 507 [Pax97a] Paxson, V., "Automated Packet Trace Analysis of TCP 508 Implementations", Proceedings of ACM SIGCOMM '97, August 1997. 510 [Pax97b] Paxson, V., "End-to-End Internet Packet Dynamics," 511 Proceedings of SIGCOMM '97, Cannes, France, Sep. 1997. 513 [PFTK98] Padhye, J., Firoiu. V., Towsley, D., and Kurose, J., "TCP 514 Throughput: A Simple Model and its Empirical Validation", 515 Proceedings of ACM SIGCOMM '98, August 1998. 517 [RFC793] Postel, J., "Transmission Control Protocol", 1981, Obtain 518 via: ftp://ds.internic.net/rfc/rfc793.txt 520 [RFC1191] Mogul, J., Deering, S., "Path MTU Discovery", November 521 1990, Obtain via: ftp://ds.internic.net/rfc/rfc1191.txt 523 [RFC1323] Jacobson, V., Braden, R., Borman, D., "TCP Extensions for 524 High Performance", May 1992, Obtain via: 525 ftp://ds.internic.net/rfc/rfc1323.txt 527 [RFC1633] Braden R., Clark D., Shenker S., "Integrated Services in 528 the Internet Architecture: an Overview"., 1994. 530 [RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast 531 Retransmit, and Fast Recovery Algorithms", 1997, Obtain via: 532 ftp://ds.internic.net/rfc/rfc2001.txt 534 [RFC2018] Mathis, M., Mahdavi, J. Floyd, S., Romanow, A., "TCP 535 Selective Acknowledgment Options", 1996, Obtain via: 536 ftp://ds.internic.net/rfc/rfc2018.txt 538 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 539 Requirement Levels", 1997, Obtain via: 540 ftp://ds.internic.net/rfc/rfc2119.txt 542 [RFC2216] Shenker, S., Wroclawski, J., "Network Element Service 543 Specification Template", 1997, Obtain via: 544 ftp://ds.internic.net/rfc/rfc2216.txt 546 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., Mathis, M., "Framework 547 for IP Performance Metrics" , 1998, Obtain via: 548 ftp://ds.internic.net/rfc/rfc2330.txt 550 [RFC2475] Black D., Blake S., Carlson M., Davies E., Wang Z., Weiss 551 W., "An Architecture for Differentiated Services"., 1998. 553 [RFC2481] K. Ramakrishnan, S. Floyd, "A Proposal to add Explicit 554 Congestion Notification (ECN) to IP", 1999, Obtain via: 555 ftp://ds.internic.net/rfc/rfc2481.txt 557 [RFC2525] V. Paxson, M. Allman, S. Dawson, W. Fenner, J. Griner, 558 I. Heavens, K. Lahey, J. Semke, B. Volz, "Known TCP 559 Implementation Problems", 1999, Obtain via: 560 ftp://ds.internic.net/rfc/rfc2525.txt 562 [RFC2581] Allman, M., Paxson, V., Stevens, W., "TCP Congestion 563 Control"., 1999, Obtain via: 564 ftp://ds.internic.net/rfc/rfc2581.txt 566 [RFC2582] Floyd, S., Henderson, T., "The NewReno Modification to 567 TCP's Fast Recovery Algorithm", 1999, Obtain via: 568 ftp://ds.internic.net/rfc/rfc2582.txt 570 [RFC2988] Paxson, V., Allman, M., "Computing TCP's Retransmission 571 Timer", November 2000, Obtain via: 572 ftp://ds.internic.net/rfc/rfc2988.txt 574 [Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols", 575 Addison-Wesley, 1994. 577 [WS95] Wright, G., Stevens, W., "TCP/IP Illustrated Volume II: The 578 Implementation", Addison-Wesley, 1995. 580 Author's Addresses 582 Matt Mathis 583 Pittsburgh Supercomputing Center 584 4400 Fifth Ave. 585 Pittsburgh PA 15213 586 mathis@psc.edu 587 http://www.psc.edu/~mathis 589 Mark Allman 590 NASA Glenn Research Center/BBN Technologies 591 Lewis Field 592 21000 Brookpark Rd. MS 54-2 593 Cleveland, OH 44135 594 216-433-6586 595 mallman@grc.nasa.gov 596 http://roland.grc.nasa.gov/~mallman