idnits 2.17.1 draft-ietf-ippm-btc-framework-05.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 647 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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) == Missing Reference: 'ABF00' is mentioned on line 228, but not defined == Unused Reference: 'Flo95' is defined on line 491, but no explicit reference was found in the text == Unused Reference: 'Hoe95' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'LK98' is defined on line 507, but no explicit reference was found in the text == Unused Reference: 'OKM96b' is defined on line 545, but no explicit reference was found in the text == Unused Reference: 'Pax97a' is defined on line 550, but no explicit reference was found in the text == Unused Reference: 'RFC793' is defined on line 560, but no explicit reference was found in the text == Unused Reference: 'RFC2001' is defined on line 574, but no explicit reference was found in the text == Unused Reference: 'RFC2018' is defined on line 578, but no explicit reference was found in the text == Unused Reference: 'RFC2525' is defined on line 602, but no explicit reference was found in the text == Unused Reference: 'RFC3042' is defined on line 619, but no explicit reference was found in the text == Unused Reference: 'Ste94' is defined on line 623, but no explicit reference was found in the text == Unused Reference: 'WS95' is defined on line 626, 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: 17 errors (**), 0 flaws (~~), 15 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 BBN/NASA Glenn 7 February, 2001 9 A Framework for Defining Empirical Bulk Transfer Capacity Metrics 11 < draft-ietf-ippm-btc-framework-05.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'' bits transfered 83 (i.e., not including header bits or emulated header bits). Also 84 note that the amount of data sent should only include the unique 85 number of bits 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]. The algorithm used in a 196 particular BTC methodology MUST be defined. 198 * [RFC2581] does not specify which cwnd increase algorithm (slow 199 start or congestion avoidance) should be used when cwnd equals 200 ssthresh. This MUST be specified for each BTC methodology. 202 * [RFC2581] allows TCPs to use advanced loss recovery mechanism 203 such as NewReno [RFC2582,FF96,Hoe96] and SACK-based algorithms 204 [FF96,MM96a,MM96b]. If used in a BTC implementation, such an 205 algorithm MUST be fully defined. 207 * The actual segment size, or method of choosing a segment size 208 (e.g., path MTU discovery [RFC1191]) and the number of header 209 bytes assumed to be prepended to each segment MUST be specified. 210 In addition, if the segment size is artificially limited to less 211 than the path MTU this MUST be indicated. 213 * TCP includes a retransmission timeout (RTO) to trigger 214 retransmissions of segments that have not been acknowledged 215 within an appropriate amount of time and have not been 216 retransmitted via some more advanced loss recovery algorithm. A 217 BTC implementation MUST include a retransmission timer. 218 Calculating the RTO is subject to a number of details that MUST 219 be defined for each BTC metric. In addition, a BTC metric MUST 220 define when the clock is set and the granularity of the clock. 222 [RFC2988] specifies the behavior of the retransmission timer. 223 However, there are several details left to the implementer which 224 MUST be specified for each BTC metric defined. 226 Note that as new congestion control algorithms are placed on the 227 standards track they may be incorporated into BTC metrics (e.g., the 228 Limited Transmit algorithm [ABF00]). However, any implementation 229 decisions provided by the relevant RFCs SHOULD be fully specified in 230 the particular BTC metric. 232 3 Ancillary Metrics 234 The following ancillary metrics can provide additional information 235 about the network and the behavior of the implemented congestion 236 control algorithms in response to the behavior of the network path. 237 It is RECOMMENDED that these metrics be built into each BTC 238 methodology. Alternatively, it is RECOMMENDED that the BTC 239 implementation provide enough information such that the ancillary 240 metrics can be derived via post-processing (e.g., by providing a 241 segment trace of the connection). 243 3.1 Congestion Avoidance Capacity 245 The "Congestion Avoidance Capacity" (CAC) metric is the data rate 246 (bits per second) of a fully specified implementation of the 247 Congestion Avoidance algorithm, subject to the restriction that the 248 Retransmission Timeout and Slow-Start algorithms are not invoked. 249 The CAC metric is defined to have no meaning across Retransmission 250 Timeouts or Slow-Start periods (except the single segment Slow-Start 251 that is permitted to follow recovery, as discussed in section 2). 253 In principle a CAC metric would be an ideal BTC metric, as it 254 captures what should be TCP's steady state behavior. But, there is 255 a rather substantial difficulty with using it as such. The 256 Self-Clocking of the Congestion Avoidance algorithm can be very 257 fragile, depending on the specific details of the Fast Retransmit, 258 Fast Recovery or advanced recovery algorithms chosen. It has been 259 found that timeouts and periods of slow start loss recovery are 260 prevalent in traffic on the Internet [LK98,BPS+97] and therefore these 261 should be captured by the BTC metric. 263 When TCP loses Self-Clock it is re-established through a 264 retransmission timeout and Slow-Start. These algorithms nearly 265 always require more time than Congestion Avoidance would have taken. 266 It is easily observed that unless the network loses an entire window 267 of data (which would clearly require a retransmit timeout) TCP 268 likely missed some opportunity to safely transmit data. That is, if TCP 269 experiences a timeout after losing a partial window of data, it must 270 have received at least one ACK that was generated after some of the 271 partial data was delivered, but did not trigger the transmission of 272 new data. Recent research in congestion control (e.g., FACK 273 [MM96a], NewReno [FF96,RFC2582], rate-halving [MSML99]) can be 274 characterized as making TCP's Self-Clock more tenacious, while 275 preserving fairness under adverse conditions. This work is 276 motivated by how poorly current TCP implementations perform under 277 some conditions, often due to repeated clock loss. Since this is an 278 active research area, different TCP implementations have rather 279 considerable differences in their ability to preserve Self-Clock. 281 3.2 Preservation of Self-Clock 283 Losing the ACK clock can have a large effect on the overall BTC, and 284 the clock is itself fragile in ways that are dependent on the loss 285 recovery algorithm. Therefore, the transition between timer driven 286 and Self-Clocked operation SHOULD be instrumented. 288 3.2.1 Lost Transmission Opportunities 290 If the last event before a timeout was the receipt of an ACK that 291 did not trigger a transmission, the possibility exists that an 292 alternate congestion control algorithm would have successfully 293 preserved the Self-Clock. A BTC SHOULD instrument key items in the 294 BTC state (such as the congestion window) in the hopes that this may 295 lead to further improvements in congestion control algorithms. 297 Note that in the absence of knowledge about the future, it is not 298 possible to design an algorithm that never misses transmission 299 opportunities. However, there are ever more subtle ways to gauge 300 network state, and to estimate if a given ACK is likely to be the 301 last. 303 3.2.2 Loosing an Entire Window 305 If an entire window of data (or ACKs) is lost, there will be no 306 returning ACKs to clock out additional data. This condition can 307 be detected if the last event before a timeout was a data 308 transmission triggered by an ACK. The loss of an entire window 309 of data/ACKs forces recovery to be via a Retransmission Timeout and 310 Slow-Start. 312 Losing an entire window of data implies an outage with a duration at 313 least as long as a round trip time. Such an outage can not be 314 diagnosed with low rate metrics and is unsafe to diagnose at higher 315 rates than the BTC. Therefore all BTC metrics SHOULD instrument and 316 report losses of an entire window of data. 318 Note that there are some conditions, such as when operating with a 319 very small window, in which there is a significant probability that 320 an entire window can be lost through individual random losses (again 321 highlighting the importance of instrumenting cwnd). 323 3.2.3 Heroic Clock Preservation 325 All algorithms that permit a given BTC to sustain Self-Clock when 326 other algorithms might not, SHOULD be instrumented. Furthermore, 327 the details of the algorithms used MUST be fully documented (as 328 discussed in section 2). 330 BTC metrics that can sustain Self-Clock in the presence of multiple 331 losses within one round trip SHOULD instrument the loss 332 distribution, such that the performance of alternate congestion 333 control algorithms may be estimated (e.g., Reno style). 335 3.2.4 False Timeouts 337 All false timeouts, (where the retransmission timer expires before 338 the ACK for some previously transmitted data arrives) SHOULD be 339 instrumented when possible. Note that depending upon how the BTC 340 metric implements sequence numbers, this may be difficult to detect. 342 3.3 Ancillary Metrics Relating to Flow Based Path Properties 344 All BTC metrics provide unique vantage points for observing certain 345 path properties relating to closely spaced packets. As in the case 346 of RTT duration outages, these can be impossible to diagnose at low 347 rates (less than 1 packet per RTT) and inappropriate to test at 348 rates above the BTC of the network path. 350 All BTC metrics SHOULD instrument packet reordering. The frequency 351 and distance out-of-sequence SHOULD be instrumented for all 352 out-of-order packets. The severity of the reordering can be 353 classified as one of three different cases, each of which SHOULD be 354 reported. 356 Segments that are only slightly out-of-order should not trigger 357 the fast retransmit algorithm, but they may affect the window 358 calculation. BTC metrics SHOULD document how slightly 359 out-of-order segments affect the congestion window calculation. 361 If segments are sufficiently out-of-order, the Fast Retransmit 362 algorithm will be invoked in advance of the delayed packet's 363 late arrival. These events SHOULD be instrumented. Even though 364 the the late arriving packet will complete recovery, the the 365 window will still be reduced by half. 367 Under some rare conditions segments have been observed that are 368 far out of order - sometimes many seconds late [Pax97b]. These 369 SHOULD always be instrumented. 371 BTC implementations SHOULD instrument the maximum cwnd observed 372 during congestion avoidance and slow start. A TCP running over the 373 same path as the BTC metric must have sufficient sender buffer space 374 and receiver window (and window shift [RFC1323]) to cover this cwnd 375 in order to expect the same performance. 377 There are several other path properties that one might measure 378 within a BTC metric. For example, with an embedded one-way delay 379 metric it may be possible to measure how queueing delay and and 380 (RED) drop probabilities are correlated to window size. These are 381 open research questions. 383 3.4 Ancillary Metrics as Calibration Checks 385 Unlike low rate metrics, BTC SHOULD include explicit checks that the 386 test platform is not the bottleneck. 388 Any detected dropped packets within the sending host MUST be reported. 389 Unless the sending interface is the path bottleneck, any dropped 390 packets probably indicates a measurement failure. 392 The maximum queue lengths within the sending host SHOULD be 393 instrumented. Any significant queue may indicate that the sending 394 host has insufficient burst data rate, and is smoothing the data 395 being transmitted into the network. 397 3.5 Ancillary Metrics Relating to the Need for Advanced TCP Features 399 If TCP would require advanced TCP extensions to match BTC 400 performance (such as RFC 1323 or RFC 2018 features), it SHOULD be 401 reported. 403 3.6 Validate Reverse Path Load 405 To the extent possible, the BTC metric SHOULD distinguish between 406 the properties of the forward and reverse paths. 408 BTC methodologies which rely on non-cooperating receivers may only 409 be able to measure round trip path properties and may not be able to 410 independently differentiate between the properties of the forward 411 and reverse paths. In this case the load on the reverse path 412 contributed by the BTC metric SHOULD be instrumented (or computed) 413 to permit other means of gauge the proportion of the round trip path 414 properties attributed to the the forward and reverse paths. 416 To the extent possible, BTC methodologies that rely on cooperating 417 receivers SHOULD support separate ancillary metrics for the forward 418 and reverse paths. 420 4 Security Considerations 422 Conducting Internet measurements raises security concerns. This 423 memo does not specify a particular implementation of a metric, so it 424 does not directly affect the security of the Internet nor of 425 applications which run on the Internet. However, metrics produced 426 within this framework, and in particular implementations of the 427 metrics may create security issues. 429 4.1 Denial of Service Attacks 431 Bulk Transport Capacity metrics, as defined in this document, 432 naturally attempt to fill a bottleneck link. The BTC metrics based 433 on this specification will be as ``network friendly'' as current 434 well-tuned TCP connections. However, since the ``connection'' may 435 not be using TCP packets, a BTC test may appear to network operators 436 as a denial of service attack. 438 Administrators of the source host of a test, the destination host of 439 a test, and the intervening network(s) may wish to establish 440 bilateral or multi-lateral agreements regarding the timing, size, 441 and frequency of collection of BTC metrics. 443 4.2 User data confidentiality 445 Metrics within this framework generate packets for a sample, rather 446 than taking samples based on user data. Thus, a BTC metric does not 447 threaten user data confidentiality. 449 4.3 Interference with metrics 451 It may be possible to identify that a certain packet or stream of 452 packets are part of a BTC metric. With that knowledge at the 453 destination and/or the intervening networks, it is possible to 454 change the processing of the packets (e.g. increasing or decreasing 455 delay, introducing or heroically preventing loss) that may distort 456 the measured performance. It may also be possible to generate 457 additional packets that appear to be part of a BTC metric. These 458 additional packets are likely to perturb the results of the sample 459 measurement. 461 To discourage the kind of interference mentioned above, packet 462 interference checks, such as cryptographic hash, may be used. 464 5 IANA Considerations 466 Since this metric framework does not define a specific 467 protocol, nor does it define any well-known values, there 468 are no IANA considerations for this document. However, 469 a bulk transport capacity metric within this framework, 470 and in particular protocols that implement a metric may have 471 IANA considerations that need to be addressed. 473 6 Acknowledgments 475 Thanks to Wil Leland, Jeff Semke, Matt Zekauskas and the IPPM 476 working group for numerous clarifications. 478 7 References 480 [BPS+97] Hari Balakrishnan, Venkata Padmanabhan, Srinivasan Seshan, 481 Mark Stemm, and Randy Katz. TCP Behavior of a Busy Web Server: 482 Analysis and Improvements. Technical Report UCB/CSD-97-966, 483 August 1997. Available from 484 http://nms.lcs.mit.edu/~hari/papers/csd-97-966.ps. (Also in 485 Proc. IEEE INFOCOM Conf., San Francisco, CA, March 1998.) 487 [FF96] Fall, K., Floyd, S.. "Simulation-based Comparisons of Tahoe, 488 Reno and SACK TCP". Computer Communication Review, July 1996. 489 ftp://ftp.ee.lbl.gov/papers/sacks.ps.Z. 491 [Flo95] Floyd, S., "TCP and successive fast retransmits", March 492 1995, Obtain via ftp://ftp.ee.lbl.gov/papers/fastretrans.ps. 494 [Hoe96] Hoe, J., "Improving the start-up behavior of a congestion 495 control scheme for TCP, Proceedings of ACM SIGCOMM '96, August 496 1996. 498 [Hoe95] Hoe, J., "Startup dynamics of TCP's congestion control and 499 avoidance schemes". Master's thesis, Massachusetts Institute of 500 Technology, June 1995. 502 [Jac88] Jacobson, V., "Congestion Avoidance and Control", 503 Proceedings of SIGCOMM '88, Stanford, CA., August 1988. 505 [Lak94] Lakshman, Effects of random loss 507 [LK98] Lin, D. and Kung, H.T., "TCP Fast Recovery Strategies: 508 Analysis and Improvements", Proceedings of InfoCom, March 1998. 510 [LM97] T.V.Lakshman and U.Madhow. "The Performance of TCP/IP for 511 Networks with High Bandwidth-Delay Products and Random Loss". 512 IEEE/ACM Transactions on Networking, Vol. 5, No. 3, June 1997, 513 pp.336-350. 515 [Mat98] Mathis, M., "Empirical Bulk Transfer Capacity", IP 516 Performance Metrics Working Group report in Proceedings of the 517 Forty Third Internet Engineering Task Force, Orlando, FL, 518 December 1988. Available from 519 http://www.ietf.org/proceedings/98dec/43rd-ietf-98dec-122.html 520 and 521 http://www.ietf.org/proceedings/98dec/slides/ippm-mathis-98dec.pdf. 523 [MM96a] Mathis, M. and Mahdavi, J. "Forward acknowledgment: Refining 524 TCP congestion control", Proceedings of ACM SIGCOMM '96, 525 Stanford, CA., August 1996. 527 [MM96b] M. Mathis, J. Mahdavi, "TCP Rate-Halving with Bounding 528 Parameters" Available from 529 http://www.psc.edu/networking/papers/FACKnotes/current. 531 [MSML99] Mathis, M., Semke, J., Mahdavi, J., Lahey, K., "The 532 Rate-Halving Algorithm for TCP Congestion Control", June 1999. 533 Internet-Draft draft-mathis-tcp-ratehalving-00.txt (work in 534 progress). 536 [MSMO97] Mathis, M., Semke, J., Mahdavi, J., Ott, T., "The 537 Macroscopic Behavior of the TCP Congestion Avoidance Algorithm", 538 Computer Communications Review, 27(3), July 1997. 540 [OKM96a], Ott, T., Kemperman, J., Mathis, M., "The Stationary 541 Behavior of Ideal TCP Congestion Avoidance", In progress, August 542 1996. Obtain via pub/tjo/TCPwindow.ps using anonymous ftp to 543 ftp.bellcore.com 545 [OKM96b], Ott, T., Kemperman, J., Mathis, M., "Window Size Behavior 546 in TCP/IP with Constant Loss Probability", DIMACS Special Year 547 on Networks, Workshop on Performance of Real-Time Applications 548 on the Internet, Nov 1996. 550 [Pax97a] Paxson, V., "Automated Packet Trace Analysis of TCP 551 Implementations", Proceedings of ACM SIGCOMM '97, August 1997. 553 [Pax97b] Paxson, V., "End-to-End Internet Packet Dynamics," 554 Proceedings of SIGCOMM '97, Cannes, France, Sep. 1997. 556 [PFTK98] Padhye, J., Firoiu. V., Towsley, D., and Kurose, J., "TCP 557 Throughput: A Simple Model and its Empirical Validation", 558 Proceedings of ACM SIGCOMM '98, August 1998. 560 [RFC793] Postel, J., "Transmission Control Protocol", 1981, Obtain 561 via: http://www.rfc-editor.org/rfc/rfc793.txt 563 [RFC1191] Mogul, J., Deering, S., "Path MTU Discovery", November 564 1990, Obtain via: http://www.rfc-editor.org/rfc/rfc1191.txt 566 [RFC1323] Jacobson, V., Braden, R., Borman, D., "TCP Extensions for 567 High Performance", May 1992, Obtain via: 568 http://www.rfc-editor.org/rfc/rfc1323.txt 570 [RFC1633] Braden R., Clark D., Shenker S., "Integrated Services in 571 the Internet Architecture: an Overview", 1994, Obtain via: 572 http://www.rfc-editor.org/rfc/rfc1633.txt 574 [RFC2001] Stevens, W., "TCP Slow Start, Congestion Avoidance, Fast 575 Retransmit, and Fast Recovery Algorithms", 1997, Obtain via: 576 http://www.rfc-editor.org/rfc/rfc2001.txt 578 [RFC2018] Mathis, M., Mahdavi, J. Floyd, S., Romanow, A., "TCP 579 Selective Acknowledgment Options", 1996, Obtain via: 580 http://www.rfc-editor.org/rfc/rfc2018.txt 582 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 583 Requirement Levels", 1997, Obtain via: 584 http://www.rfc-editor.org/rfc/rfc2119.txt 586 [RFC2216] Shenker, S., Wroclawski, J., "Network Element Service 587 Specification Template", 1997, Obtain via: 588 http://www.rfc-editor.org/rfc/rfc2216.txt 590 [RFC2330] Paxson, V., Almes, G., Mahdavi, J., Mathis, M., "Framework 591 for IP Performance Metrics" , 1998, Obtain via: 592 http://www.rfc-editor.org/rfc/rfc2330.txt 594 [RFC2475] Black D., Blake S., Carlson M., Davies E., Wang Z., Weiss 595 W., "An Architecture for Differentiated Services", 1998, Obtain 596 via: http://www.rfc-editor.org/rfc/rfc2475.txt 598 [RFC2481] K. Ramakrishnan, S. Floyd, "A Proposal to add Explicit 599 Congestion Notification (ECN) to IP", 1999, Obtain via: 600 http://www.rfc-editor.org/rfc/rfc2481.txt 602 [RFC2525] V. Paxson, M. Allman, S. Dawson, W. Fenner, J. Griner, 603 I. Heavens, K. Lahey, J. Semke, B. Volz, "Known TCP 604 Implementation Problems", 1999, Obtain via: 605 http://www.rfc-editor.org/rfc/rfc2525.txt 607 [RFC2581] Allman, M., Paxson, V., Stevens, W., "TCP Congestion 608 Control"., 1999, Obtain via: 609 http://www.rfc-editor.org/rfc/rfc2581.txt 611 [RFC2582] Floyd, S., Henderson, T., "The NewReno Modification to 612 TCP's Fast Recovery Algorithm", 1999, Obtain via: 613 http://www.rfc-editor.org/rfc/rfc2582.txt 615 [RFC2988] Paxson, V., Allman, M., "Computing TCP's Retransmission 616 Timer", November 2000, Obtain via: 617 http://www.rfc-editor.org/rfc/rfc2988.txt 619 [RFC3042] Allman, M., Balakrishnan, H., Floyd, S., "Enhancing TCP's 620 Loss Recovery Using Limited Transmit", January 2001, Obtain via: 621 http://www.rfc-editor.org/rfc/rfc3042.txt 623 [Ste94] Stevens, W., "TCP/IP Illustrated, Volume 1: The Protocols", 624 Addison-Wesley, 1994. 626 [WS95] Wright, G., Stevens, W., "TCP/IP Illustrated Volume II: The 627 Implementation", Addison-Wesley, 1995. 629 Author's Addresses 631 Matt Mathis 632 Pittsburgh Supercomputing Center 633 4400 Fifth Ave. 634 Pittsburgh PA 15213 635 mathis@psc.edu 636 http://www.psc.edu/~mathis 638 Mark Allman 639 BBN Technologies/NASA Glenn Research Center 640 Lewis Field 641 21000 Brookpark Rd. MS 54-2 642 Cleveland, OH 44135 643 216-433-6586 644 mallman@bbn.com 645 http://roland.grc.nasa.gov/~mallman