idnits 2.17.1 draft-irtf-tmrg-tools-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 863. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 874. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 881. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 887. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 855), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- 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.) -- The document date (14 October 2005) is 6762 days in the past. Is this intentional? 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: 'ZSC91' is mentioned on line 357, but not defined == Missing Reference: 'QZK01' is mentioned on line 483, but not defined == Missing Reference: 'F02' is mentioned on line 485, but not defined == Unused Reference: 'FJ92' is defined on line 780, but no explicit reference was found in the text == Unused Reference: '1' is defined on line 811, but no explicit reference was found in the text == Unused Reference: 'ZCS91' is defined on line 833, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 9 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force S. Floyd 2 INTERNET-DRAFT E. Kohler 3 draft-irtf-tmrg-tools-01.txt Editors 4 Expires: April 2006 14 October 2005 6 Tools for the Evaluation of Simulation and Testbed Scenarios 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as 23 reference material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on April 2006. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). All Rights Reserved. 37 Abstract 39 This document describes tools for the evaluation of simulation and 40 testbed scenarios used in research on Internet congestion control 41 mechanisms. We believe that research in congestion control 42 mechanisms has been seriously hampered by the lack of good models 43 underpinning analysis, simulation, and testbed experiments, and that 44 tools for the evaluation of simulation and testbed scenarios can 45 help in the construction of better scenarios, based on better 46 underlying models. One use of the tools described in this document 47 is in comparing key characteristics of test scenarios with known 48 characteristics from the diverse and ever-changing real world. 49 Tools characterizing the aggregate traffic on a link include the 50 distribution of per-packet round-trip times, the distribution of 51 packet sequence numbers, and the like. Tools characterizing end-to- 52 end paths include drop rates as a function of packet size and of 53 burst size, the synchronization ratio between two end-to-end TCP 54 flows, and the like. For each characteristic, we describe what 55 aspects of the scenario determine this characteristic, how the 56 characteristic can affect the results of simulations and experiments 57 for the evaluation of congestion control mechanisms, and what is 58 known about this characteristic in the real world. We also explain 59 why the use of such tools can add considerable power to our 60 understanding and evaluation of simulation and testbed scenarios. 62 Table of Contents 64 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 66 3. Tools . . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Characterizing Aggregate Traffic on a Link . . . . . 4 68 3.2. Characterizing an End-to-End Path. . . . . . . . . . 5 69 3.3. Other Characteristics. . . . . . . . . . . . . . . . 5 70 4. Distribution of per-packet round-trip times . . . . . . . 5 71 5. Distribution of packet sequence numbers . . . . . . . . . 7 72 6. The Distribution of Packet Sizes. . . . . . . . . . . . . 8 73 7. The Ratio Between Forward-path and Reverse-path Traf- 74 fic. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 75 8. The Distribution of Per-Packet Peak Flow Rates. . . . . . 9 76 9. The Distribution of Transport Protocols.. . . . . . . . . 10 77 10. The Synchronization Ratio. . . . . . . . . . . . . . . . 10 78 11. Drop or Mark Rates as a Function of Packet Size. . . . . 12 79 12. Drop Rates as a Function of Burst Size.. . . . . . . . . 13 80 13. Drop Rates as a Function of Sending Rate.. . . . . . . . 15 81 14. Congestion Control Mechanisms for Traffic, along 82 with Sender and. . . . . . . . . . . . . . . . . . . . . . . 16 83 15. Characterization of Congested Links in Terms of 84 Bandwidth and Typical Levels of Congestion . . . . . . . . . 16 85 16. Characterization of Challenging Lower Layers.. . . . . . 16 86 17. Characterization of Network Changes Affecting Con- 87 gestion. . . . . . . . . . . . . . . . . . . . . . . . . . . 16 88 18. Using the Tools Presented in this Document . . . . . . . 16 89 19. Related Work . . . . . . . . . . . . . . . . . . . . . . 16 90 20. Conclusions. . . . . . . . . . . . . . . . . . . . . . . 16 91 21. Security Considerations. . . . . . . . . . . . . . . . . 17 92 22. IANA Considerations. . . . . . . . . . . . . . . . . . . 17 93 23. Acknowledgements . . . . . . . . . . . . . . . . . . . . 17 94 Informative References . . . . . . . . . . . . . . . . . . . 17 95 Editors' Addresses . . . . . . . . . . . . . . . . . . . . . 19 96 Full Copyright Statement . . . . . . . . . . . . . . . . . . 19 97 Intellectual Property. . . . . . . . . . . . . . . . . . . . 19 99 1. Introduction 101 This document discusses tools for the evaluation of simulation and 102 testbed scenarios used in research on Internet congestion control 103 mechanisms. These tools include but are not limited to measurement 104 tools; the tools discussed in this document are largely ways of 105 characterizing aggregate traffic on a link, or characterizing the 106 end-to-end path. One use of these tools is for understanding key 107 characteristics of test scenarios; many characteristics, such as the 108 distribution of per-packet round-trip times on the link, don't come 109 from a single input parameter but are determined by a range of 110 inputs. A second use of the tools is to compare key characteristics 111 of test scenarios with what is known of the same characteristics of 112 the past and current Internet, and with what can be conjectured 113 about these characteristics of future networks. This paper follows 114 the general approach from "Internet Research Needs Better Models" 115 [FK02]. 117 As an example of the power of tools for characterizing scenarios, a 118 great deal is known about the distribution of connection sizes on a 119 link, or equivalently, the distribution of per-packet sequence 120 numbers. It has been conjectured that a heavy-tailed distribution 121 of connection sizes is an invariant feature of Internet traffic. A 122 test scenario with mostly long-lived traffic, or with a mix with 123 only long-lived and very short flows, does not have a realistic 124 distribution of connection sizes, and can give unrealistic results 125 in simulations or experiments evaluating congestion control 126 mechanisms. For instance, the distribution of packet sequence 127 numbers makes clear the fraction of traffic on a link from medium- 128 sized connections, e.g., with packet sequence numbers from 100 to 129 1000. These medium-sized connections can slow-start up to a large 130 congestion window, possibly coming to an abrupt stop soon 131 afterwards, contributing significantly to the burstiness of the 132 aggregate traffic, and to the problems facing congestion control. 134 In the sections below we will discuss a number of tools for 135 describing and evaluating scenarios, show how these characteristics 136 can affect the results of research on congestion control mechanisms, 137 and summarize what is known about these characteristics in real- 138 world networks. 140 2. Conventions 142 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 143 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 144 document are to be interpreted as described in [RFC 2119]. 146 3. Tools 148 The tools or characteristics that we discuss are the following. 150 3.1. Characterizing Aggregate Traffic on a Link 152 o Distribution of per-packet round-trip times. 154 o Distribution of packet sequence numbers. 156 o Distribution of packet sizes. 158 o Ratio between forward-path and reverse-path traffic. 160 o Distribution of peak flow rates. 162 o Distribution of transport protocols. 164 3.2. Characterizing an End-to-End Path 166 o Synchronization ratio. 168 o Drop rates as a function of packet size. 170 o Drop rates as a function of burst size. 172 o Drop rates as a function of sending rate. 174 o Degree of packet drops. 176 o Range of queueing delay. 178 3.3. Other Characteristics 180 o Congestion control mechanisms for traffic, along with sender and 181 receiver buffer sizes. 183 o Characterization of congested links in terms of bandwidth and 184 typical levels of congestion (in terms of packet drop rates). 186 o Characterization of congested links in terms of buffer size. 188 o Characterization of challenging lower layers in terms of 189 reordering, delay variation, packet corruption, and the like. 191 o Characterization of network changes affecting congestion, such as 192 routing changes or link outages. 194 Below we will discuss each characteristic in turn, giving the 195 definition, the factors determining that characteristic, the effect 196 on congestion control metrics, and what is known so far from 197 measurement studies in the Internet. 199 4. Distribution of per-packet round-trip times 201 Definition: The distribution of per-packet round-trip times on a 202 link is defined formally by assigning to each packet the most recent 203 round trip time measured for that end-to-end connection. In 204 practice, coarse-grained information is generally sufficient, even 205 though it has been shown that there is significant variability in 206 round-trip times within a TCP connection [AKSJ03], and it is 207 sufficient to assign to each packet the first round-trip time 208 measurement for that connection, or to assign the current round-trip 209 time estimate maintained by the TCP connection. 211 Determining factors: The distribution of per-packet round-trip times 212 on a link is determined by end-to-end propagation delays, by 213 queueing delays along end-to-end paths, and by the congestion 214 control mechanisms used by the traffic. For example, for a scenario 215 using TCP, TCP connections with smaller round-trip times will 216 receive a proportionally larger fraction of traffic than competing 217 TCP connections with larger round-trip times, all else being equal, 218 due to the dynamics of TCP favoring flows with smaller round-trip 219 times. This will generally shift the distribution of per-packet 220 RTTs lower relative to the distribution of per-connection RTTs, 221 since short-RTT connections will have more packets. 223 Effect on congestion control metrics: The distribution of per-packet 224 round-trip times on a link affects the burstiness of the aggregate 225 traffic, and therefore can affect congestion control performance in 226 a range of areas such as delay/throughput tradeoffs. The 227 distribution of per-packet round-trip times can also affect metrics 228 of fairness, degree of oscillations, and the like. For example, 229 long-term oscillations of queueing delay are more likely to occur in 230 scenarios with a narrow range of round-trip times [FK02]. 232 Measurements: The distribution of per-packet round-trip times for 233 TCP traffic on a link can be measured from a packet trace with the 234 passive TCP round-trip time estimator from Jiang and Dovrolis 235 [JD02]. [Add pointers to other estimators, such as ones mentioned 236 in JD02. Add a pointer to Mark Allman's loss detection tool.] 237 Their paper shows the distribution of per-packet round-trip times 238 for TCP packets for a number of different links. For the links 239 measured, the percent of packets with round-trip times at most 240 100 ms ranged from 30% to 80%, and the percent of packets with 241 round-trip times at most 200 ms ranged from 55% to 90%, depending on 242 the link. 244 In the NS simulator, the distribution of per-packet round-trip times 245 for TCP packets on a link can be reported by the queue monitor, 246 using TCP's estimated round-trip time added to packet headers. This 247 is illustrated in the validation test "./test-all-simple stats3" in 248 the directory tcl/test. 250 Scenarios: [FK02] shows a relatively simple scenario, with a 251 dumbbell topology with four access links on each end, that gives a 252 fairly realistic range of round-trip times. [Look for the other 253 citations to add.] 255 5. Distribution of packet sequence numbers 257 Definition: The distribution of packet sequence numbers on a link is 258 defined by giving each packet a sequence number, where the first 259 packet in a connection has sequence number 1, the second packet has 260 sequence number 2, and so on. The distribution of packet sequence 261 numbers can be derived in a straightforward manner from the 262 distribution of connection sizes, and vice versa; however, the 263 distribution of connection sizes is more suited for traffic 264 generators, and the distribution of packet sequence numbers is more 265 suited for measuring and illustrating the packets actually seen on a 266 link over a fixed interval of time. There has been a considerably 267 body of research over the last ten years on the heavy-tailed 268 distribution of connection sizes for traffic on the Internet. 269 [CBC95] [Add citations.] 271 Determining factors: The distribution of connection sizes is largely 272 determined by the traffic generators used in a scenario. For 273 example, is there a single traffic generator characterized by a 274 distribution of connection sizes? A mix of long-lived and web 275 traffic, with the web traffic characterized by a distribution of 276 connection sizes? Or something else? 278 Effect on congestion control metrics: The distribution of packet 279 sequence numbers affects the burstiness of aggregate traffic on a 280 link, thereby affecting all congestion control metrics for which 281 this is a factor. As an example, [FK02] illustrates that the 282 traffic mix can affect the queue dynamics on a congested link. 283 [Find more to cite, about the effect of the distribution of packet 284 sequence numbers on congestion control metrics.] 286 [Add a paragraph about the impact of medium-size flows.] 288 [Add a paragraph about the impact of flows starting and stopping.] 290 [Add a warning about scenarios that use only long-lived flows, or a 291 mix of long-lived and very short flows.] 293 Measurements: [Cite some of the literature.] 295 Traffic generators: Some of the available traffic generators are 296 listed on the web site for "Traffic Generators for Internet Traffic" 297 [TG]. This includes pointers to traffic generators for peer-to-peer 298 traffic, traffic from online games, and traffic from Distributed 299 Denial of Service (DDoS) attacks. 301 In the NS simulator, the distribution of packet sequence numbers for 302 TCP packets on a link can be reported by the queue monitor at a 303 router. This is illustrated in the validation test "./test-all- 304 simple stats3" in the directory tcl/test. 306 6. The Distribution of Packet Sizes 308 Definition: The distribution of packet sizes is defined in a 309 straightforward way, using packet sizes in bytes. 311 Determining factors: The distribution of packet sizes is determined 312 by the traffic mix, the path MTUs, and by the packet sizes used by 313 the transport-level senders. 315 The distribution of packet sizes on a link is also determined by the 316 mix of forward-path TCP traffic and reverse-path TCP traffic in that 317 scenario, for a scenario characterized by a `forward path' (e.g., 318 left to right on a particular link) and a `reverse path' (e.g., 319 right to left on the same link). For such a scenario, the forward- 320 path TCP traffic contributes data packets to the forward link and 321 acknowledgment packets to the reverse link, while the reverse-path 322 TCP traffic contributes small acknowledgment packets to the forward 323 link. The ratio between TCP data and TCP ACK packets on a link can 324 be used as some indication of the ratio between forward-path and 325 reverse-path TCP traffic. 327 Effect on congestion control metrics: The distribution of packet 328 sizes on a link is an indicator of the ratio of forward-path and 329 reverse-path TCP traffic in that network. The amount of reverse- 330 path traffic determines the loss and queueing delay experienced by 331 acknowledgement packets on the reverse path, significantly affecting 332 the burstiness of the aggregate traffic on the forward path. [In 333 what other ways does the distribution of packet sizes affect 334 congestion control metrics?] 336 Measurements: There has been a wealth of measurements over time on 337 the packet size distribution of traffic [A00], [HMTG01]. These 338 measurements are generally consistent with a model of roughly 10% of 339 the TCP connections using an MSS of roughly 500 bytes, and with the 340 other 90% of TCP connections using an MSS of 1460 bytes. 342 7. The Ratio Between Forward-path and Reverse-path Traffic 344 Definition: For a scenario characterized by a `forward path' (e.g., 345 left to right on a particular link) and a `reverse path' (e.g., 346 right to left on the same link), the ratio between forward-path and 347 reverse-path traffic can be defined as the ratio between the 348 forward-path traffic in bps, and the reverse-path traffic in bps. 350 Determining factors: The ratio between forward-path and reverse-path 351 traffic is defined largely by the traffic mix. 353 Effect on congestion control metrics: Zhang, Shenker and Clark have 354 shown in 1991 that for TCP, the amount of reverse-path traffic 355 affects the ACK compression and packet drop rate for TCP 356 acknowledgement packets, significantly affecting the burstiness of 357 TCP traffic on the forward path [ZSC91]. The queueing delay on the 358 reverse path also affects the performance of delay-based congestion 359 control mechanisms, if the delay is computed based on round-trip 360 times. This has been shown by Grieco and Mascolo in [GM04] and by 361 Prasad, Jain, and Dovrolis in [PJD04]. 363 Measurements: There is a need for measurements on the range of 364 ratios between forward-path and reverse-path traffic for congested 365 links. In particular, for TCP traffic traversing congested link X, 366 what is the likelihood that the acknowledgement traffic will 367 encounter congestion (i.e., queueing delay, packet drops) somewhere 368 on the reverse path as well? 370 As discussed in Section 6, the distribution of packet sizes on a 371 link can be used as an indicator of the ratio of forward-path and 372 reverse-path TCP traffic in that network. 374 8. The Distribution of Per-Packet Peak Flow Rates 376 Definition: The distribution of peak flow rates is defined by 377 assigning to each packet the peak sending rate in bytes per second 378 of that connection, where the peak sending rate is defined over 379 0.1-second intervals. The distribution of peak flow rates gives 380 some indication of the ratio of "alpha" and "beta" traffic on a 381 link, where alpha traffic on a congested link is defined as traffic 382 with that link at the main bottleneck, while the beta traffic on the 383 link has a primary bottleneck elsewhere along its path [RSB01]. 385 Determining factors: The distribution of peak flow rates is 386 determined by flows with bottlenecks elsewhere along their end-to- 387 end path, e.g., flows with low-bandwidth access links. The 388 distribution of peak flow rates is also affected by applications 389 with limited sending rates. 391 Effect on congestion control metrics: The distribution of peak flow 392 rates affects the burstiness of aggregate traffic, with low-peak- 393 rate traffic decreasing the aggregate burstiness, and adding to the 394 traffic's tractability. 396 Measurements: [RSB01]. The distribution of peak rates can be 397 expected to change over time, as there is an increasing number of 398 high-bandwidth access links to the home, and of high-bandwidth 399 Ethernet links at work and at other institutions. 401 Simulators: [For NS, add a pointer to the DelayBox, 402 "http://dirt.cs.unc.edu/delaybox/", for more easily simulating low- 403 bandwidth access links for flows.] 405 Testbeds: In testbeds, Dummynet [Dummynet] and NISTNet [NISTNet] 406 provide convenient ways to emulate paths with different limited peak 407 rates. 409 9. The Distribution of Transport Protocols. 411 Definition: The distribution of transport protocols on a congested 412 link is straightforward, with each packet given its associated 413 transport protocol (e.g., TCP, UDP). The distribution is often 414 given both in terms of packets and in terms of bytes. 416 For UDP packets, it might be more helpful to classify them in terms 417 of the port number, or the assumed application (e.g., DNS, RIP, 418 games, Windows Media, RealAudio, RealVideo, etc.) [MAWI]). Other 419 traffic includes ICMP, IPSEC, and the like. In the future there 420 could be traffic from SCTP, DCCP, or from other transport protocols. 422 Effect on congestion control metrics: The distribution of transport 423 protocols affects metrics relating to the effectiveness of AQM 424 mechanisms on a link. 426 Measurements: In the past, TCP traffic has typically consisted of 427 90% to 95% of the bytes on a link [UW02], [UA01]. [Get updated 428 citations for this.] Measurement studies show that TCP traffic from 429 web servers almost always uses conformant TCP congestion control 430 procedures [MAF05]. 432 10. The Synchronization Ratio 434 Definition: The synchronization ratio is defined as the degree of 435 synchronization of loss events between two TCP flows on the same 436 path. Thus, the synchronization ratio is defined as a 437 characteristic of an end-to-end path. When one TCP flow of a pair 438 has a loss event, the synchronization ratio is given by the fraction 439 of those loss events for which the second flow has a loss event 440 within one round-trip time. Each connection in a flow pair has a 441 separate synchronization ratio, and the overall synchronization 442 ratio of the pair of flows is the higher of the two ratios. When 443 measuring the synchronization ratio, it is preferable to start the 444 two TCP flows at slightly different times, with large receive 445 windows. 447 Determining factors: The synchronization ratio is determined largely 448 by the traffic mix on the congested link, and by the AQM mechanism 449 (or lack of AQM mechanism). 451 Different types of TCP flows are also likely to have different 452 synchronization measures. E.g., Two HighSpeed TCP flows might have 453 higher synchronization measures that two Standard TCP flows on the 454 same path, because of their more aggressive window increase rates. 455 Raina, Towsley, and Wischik [RTW05] have discussed the relationships 456 between synchronization and TCP's increase and decrease parameters. 458 Effect on congestion control metrics: The synchronization ratio 459 affects convergence times for high-bandwidth TCPs. Convergence 460 times are known to be poor for some high-bandwidth protocols in 461 environments with high levels of synchronization. [Cite the papers 462 by Leith and Shorten.] However, it is not clear if these 463 environments with high levels of synchronization are realistic. 465 Wischik and MeKweon [WM05] have shown that the level of 466 synchronization affects the buffer requirements at congested 467 routers. Baccelli and Hong [BH02] have a model showing the effect 468 of the synchronization ratio on aggregate throughput. 470 Measurements: Grenville Armitage and Qiang Fu have performed initial 471 experiments of synchronization in the Internet, using Standard TCP 472 flows, and have found very low levels of synchronization. 474 In a discussion of the relationship between stability and 475 desynchronization, Raina, Towsley, and Wischik [RTW05] report that 476 "synchronization has been reported again and again in simulations". 477 In contrast, synchronization has not been reported again and again 478 in the real-world Internet. 480 Appenzeller, Keslassy, and McKeown in [AKM04] report the following: 481 "Flows are not synchronized in a backbone router carrying thousands 482 of flows with varying RTTs. Small variations in RTT or processing 483 time are sufficient to prevent synchronization [QZK01]; and the 484 absence of synchronization has been demonstrated in real networks 485 [F02, IMD01]." 487 [Appenzeller et al, Sizing Router Buffers, reports that 488 synchronization is rare as the number of competing flows increases. 489 Kevin Jeffay has some results on synchronization also.] 491 Needed: We need measurements of the synchronization ratio for flows 492 that use high-bandwidth protocols over high-bandwidth paths, given 493 typical levels of competing traffic and with typical queuing 494 mechanisms at routers (whatever these are), to see if there are 495 higher levels of synchronization with high-bandwidth protocols such 496 as HighSpeed TCP, Fast TCP, and the like, which are more aggressive 497 than Standard TCP. The assumption would be that in many 498 environments, high-bandwidth protocols have higher levels of 499 synchronization than flows using Standard TCP. 501 11. Drop or Mark Rates as a Function of Packet Size 503 Definition: Drop rates as a function of packet size are defined by 504 the actual drop rates for different packets on an end-to-end path or 505 on a congested link over a particular time interval. In some cases, 506 e.g., Drop-Tail queues in units of packets, general statements can 507 be made; e.g., that large and small packets will experience the same 508 packet drop rates. However, in other cases, e.g., Drop-Tail queues 509 in units of bytes, no such general statement can be made, and the 510 drop rate as a function of packet size will be determined in part by 511 the traffic mix at the congested link at that point of time. 513 Determining factors: The drop rate as a function of packet size is 514 determined in part by the queue architecture. E.g., is the Drop- 515 Tail queue in units of packets, of bytes, of 60-byte buffers, or of 516 a mix of buffer sizes? Is the AQM mechanism in packet mode, 517 dropping each packet with the same probability, or in byte mode, 518 with the probability of dropping or marking a packet being 519 proportional to the packet size in bytes. 521 The effect of packet size on drop rate would also be affected by the 522 presence of preferential scheduling for small packets, or by 523 differential scheduling for packets from different flows (e.g., per- 524 flow scheduling, or differential scheduling for UDP and TCP 525 traffic). 527 In many environments, the drop rate as a function of packet size 528 will be heavily affected by the traffic mix at a particular time. 529 For example, is the traffic mix dominated by large packets, or by 530 smaller ones? In some cases, the overall packet drop rate could 531 also affect the relative drop rates for different packet sizes. 533 In wireless networks, the drop rate as a function of packet size is 534 also determined by the packet corruption rate as a function of 535 packet size. [Cite Deborah Pinck's papers on Satellite-Enhanced 536 Personal Communications Experiments and on Experimental Results from 537 Internetworking Data Applications Over Various Wireless Networks 538 Using a Single Flexible Error Control Protocol.] [Cite the general 539 literature.] 541 Effect on congestion control metrics: The drop rate as a function of 542 packet size has a significant effect on the performance of 543 congestion control for VoIP and other small-packet flows. 544 [Citation: "TFRC for Voice: the VoIP Variant", draft-ietf-dccp-tfrc- 545 voip-02.txt, and earlier papers.] The drop rate as a function of 546 packet size also has an effect on TCP performance, as it affects the 547 drop rates for TCP's SYN and ACK packets. [Citation: Jeffay and 548 others.] 550 Measurements: We need measurements of the drop rate as a function of 551 packet size over a wide range of paths, or for a wide range of 552 congested links. For tests of relative drop rates on end-to-end 553 packets, one possibility would be to run successive TCP connections 554 with 200-byte, 512-byte, and 1460-byte packets, and to compare the 555 packet drop rates. The ideal test would include running TCP 556 connections on the reverse path, to measure the drop rates for the 557 small ACK packets on the forward path. It would also be useful to 558 characterize the difference in drop rates for 200-byte TCP packets 559 and 200-byte UDP packets, even though some of this difference could 560 be due to the relative burstiness of the different connections. 562 Ping experiments could also be used to get measurements of drop 563 rates as a function size, but it would be necessary to make sure 564 that the ping sending rates were adjusted to be TCP-friendly. 566 [Cite the known literature on drop rates as a function of packet 567 size.] 569 Our conjecture is that there is a wide range of behaviors for this 570 characteristic in the real world. Routers include Drop-Tail queues 571 in packets, bytes, and buffer sizes in between; these will have 572 quite different drop rates as a function of packet size. Some 573 routers include RED in byte mode (the default for RED in Linux) and 574 some have RED in packet mode (Cisco, I believe). This also affects 575 drop rates as a function of packet size. 577 Some routers on congested access links use per-flow scheduling. In 578 this case, does the per-flow scheduling have the goal of fairness in 579 *bytes* per second or in *packets* per second? What effect does the 580 per-flow scheduling have on the drop rate as a function of packet 581 size, for packets in different flows (e.g., a small-packet VoIP flow 582 competing against a large-packet TCP flow) or for packets within the 583 same flow (small ACK packets and large data packets on a two-way TCP 584 connection). 586 12. Drop Rates as a Function of Burst Size. 588 Definition: Burst-tolerance, or drop rates as a function of burst 589 size, can be defined in terms of an end-to-end path, or in terms of 590 aggregate traffic on a congested link. 592 The burst-tolerance of an end-to-end path is defined in terms of 593 connections with different degrees of burstiness within a round-trip 594 time. When packets are sent in bursts of N packets, does the drop 595 rate vary as a function of N? For example, if the TCP sender sends 596 small bursts of K packets, for K less than the congestion window, 597 how does the size of K affect the loss rate? Similarly, for a ping 598 tool sending pings at a certain rate in packets per second, one 599 could see how the clustering of the ping packets in clusters of size 600 K affects the packet drop rate. As always with such ping 601 experiments, it would be important to adjust the sending rate to 602 maintain a longer-term sending rate that was TCP-friendly. 604 Determining factors: The burst-tolerance is determined largely by 605 the AQM mechanisms for the congested routers on a path, and by the 606 traffic mix. For a Drop-Tail queue with only a small number of 607 competing flows, the burst-tolerance is likely to be low, and for 608 AQM mechanisms where the packet drop rate is a function of the 609 average queue size rather than the instantaneous queue size, the 610 burst tolerance should be quite high. 612 Effect on congestion control metrics: The burst-tolerance of the 613 path or congested link can affect fairness between competing flows 614 with different round-trip times; for example, Standard TCP flows 615 with longer round-trip times are likely to have a more bursty 616 arrival pattern at the congested link that that of Standard TCP 617 flows with shorter round-trip times. As a result, in environment 618 with low burst tolerance (e.g., scenarios with Drop-Tail queues), 619 longer-round-trip-time TCP connections can see higher packet drop 620 rates than other TCP connections, and receive an even smaller 621 fraction of the link bandwidth than they would otherwise. 622 [FJ92](Section 3.2). We note that some TCP traffic is inherently 623 bursty, e.g., Standard TCP without rate-based pacing, particularly 624 in the presence of dropped ACK packets or of ACK compression. The 625 burst-tolerance of a router can also affect the delay-throughput 626 tradeoffs and packet drop rates of the path or of the congested 627 link. 629 Measurements: One could measure the burst-tolerance of an end-to-end 630 path by running successive TCP connections, forcing bursts of size 631 at least K by dropping an appropriate fraction of the ACK packets to 632 the TCP receiver. Alternately, if one had control of the TCP 633 sender, one could modify the TCP sender to send bursts of K packets 634 when the congestion window was K or more segments. 636 [Look at Crovella's paper on loss pairs.] 638 [Look at: M. Allman and E. Blanton, "Notes on Burst Mitigation for 639 Transport Protocols", ACM Computer Communication Review, vol. 35(2), 640 (2005).] 642 Making inferences about the AQM mechanism for the congested router 643 on an end-to-end path: One potential use of measurement tools for 644 determining the burst-tolerance of an end-to-end path would be to 645 make inferences about the presence or absence of an AQM mechanism at 646 the congested link or links. As a simple test, one could run a TCP 647 connection until the connection comes out of slow-start. If the 648 receive window of the TCP connection was sufficiently high that the 649 connection exited slow-start with packet drops or marks instead of 650 because of the limitation of the receive window, one could record 651 the congestion window at the end of slow-start, and the number of 652 packets dropped from this window. A high packet drop rate might be 653 more typical of a Drop-Tail queue with small-scale statistical 654 multiplexing on the congested link, and a single packet drop coming 655 out of slow-start would suggest an AQM mechanism at the congested 656 link. 658 The synchronization measure could also add information about the 659 likely presence or absence of AQM on the congested link(s) of an 660 end-to-end path, with paths with higher levels of synchronization 661 being more likely to have Drop-Tail queues with small-scale 662 statistical multiplexing on the congested link(s). 664 [Cite the relevant literature about tools for determining the AQM 665 mechanism on an end-to-end path.] 667 13. Drop Rates as a Function of Sending Rate. 669 Definition: Drop rates as a function of sending rate is defined in 670 terms of the drop behavior of a flow in the end-to-end path. That 671 is, does the sending rate of an individual flow affect its own 672 packet drop rate, or its packet drop rate largely independent of the 673 sending rate of the flow? 675 Determining factors: The sending rate of the flow affects its own 676 packet drop rate in an environment with small-scale statistical 677 multiplexing on the congested link. The packet drop rate is largely 678 independent of the sending rate in an environment with large-scale 679 statistical multiplexing, with many competing small flows at the 680 congested link. Thus, the behavior of drop rates as a function of 681 sending rate is a rough measure of the level of statistical 682 multiplexing on the congested links of an end-to-end path. 684 Effect on congestion control metrics: The level of statistical 685 multiplexing at the congested link can affect the performance of 686 congestion control mechanisms in transport protocols. For example, 687 delay-based congestion control is often better suited to 688 environments small-scale statistical multiplexing at the congested 689 link, where the transport protocol responds to the delay caused by 690 its own sending rate. 692 Measurements: In a simulation or testbed, the level of statistical 693 multiplexing on the congested link can be observed directly. In the 694 Internet, the level of statistical multiplexing on the congested 695 links of an end-to-end path can be inferred indirectly through per- 696 flow measurements, by observing whether the packet drop rate varies 697 as a function of the sending rate of the flow. 699 14. Congestion Control Mechanisms for Traffic, along with Sender and 700 Receiver Buffer Sizes." 702 Effect on congestion control metrics: Please don't evaluate AQM 703 mechanisms by using Reno TCP, or evaluate new transport protocols by 704 comparing them with the performance of Reno TCP! For an 705 explanation, see [FK02](Section 3.4). 707 Measurements: See [MAF05]. 709 15. Characterization of Congested Links in Terms of Bandwidth and 710 Typical Levels of Congestion 712 [Pointers to the current state of our knowledge.] 714 16. Characterization of Challenging Lower Layers. 716 [This will just be a short set of pointers to the relevant 717 literature, which is quite extensive.] 719 17. Characterization of Network Changes Affecting Congestion 721 [Pointers to the current state of our knowledge.] 723 18. Using the Tools Presented in this Document 725 [To be done.] 727 19. Related Work 729 [Cite "On the Effective Evaluation of TCP" by Allman and Falk.] 731 20. Conclusions 733 [To be done.] 735 21. Security Considerations 737 There are no security considerations in this document. 739 22. IANA Considerations 741 There are no IANA considerations in this document. 743 23. Acknowledgements 745 Thanks to Xiaoliang (David) Wei for feedback and contributions to 746 this document. 748 Informative References 750 [RFC 2119] S. Bradner. Key Words For Use in RFCs to Indicate 751 Requirement Levels. RFC 2119. 753 [MAWI] M.W. Group, Mawi working group traffic archive, URL 754 "http://tracer.csl.sony.jp/mawi/". 756 [AKM04] B. Appenzeller, I. Keslassy, and N. McKeown, Sizing Router 757 Buffers, SIGCOMM 2004. 759 [AKSJ03] J. Aikat, J. Kaur, F.D. Smith, and K. Jeffay, Variability 760 in TCP Roundtrip Times, ACM SIGCOMM Internet Measurement 761 Conference, Maimi, FL, October 2003, pp. 279-284. 763 [A00] M. Allman, A Web Server's View of the Transport Layer, 764 Computer Communication Review, 30(5), October 200. 766 [BH02] F. Baccelli and D. Hong, AIMD, Fairness and Fractal Scaling 767 of TCP Traffic, Infocom 2002. 769 [CBC95] C. Cunha, A. Bestavros, and M. Crovella, "Characteristics of 770 WWW Client-based Traces", BU Technical Report BUCS-95-010, 1995. 772 [Dummynet] L. Rizzo, Dummynet, URL 773 "http://info.iet.unipi.it/~luigi/ip_dummynet/". 775 BIBREF F02 "F02" C. J. Fraleigh, Provisioning Internet Backbone 776 Networks to Support Latency Sensitive Applications. PhD thesis, 777 Stanford University, Department of Electrical Engineering, June 778 2002. 780 [FJ92] S. Floyd and V. Jacobson, On Traffic Phase Effects in Packet- 781 Switched Gateways, Internetworking: Research and Experience, V.3 782 N.3, September 1992, p.115-156. 784 [FK02] S. Floyd and E. Kohler, Internet Research Needs Better 785 Models, Hotnets-I, October 2002. 787 [GM04] L. Grieco and S. Mascolo, Performance Evaluation and 788 Comparison of Westwood+, New Reno, and Vegas TCP Congestion 789 Control, CCR, April 2004. 791 [HMTG01] C. Hollot, V. Misra, D. Towsley, and W. Gong, On Designing 792 Improved Controllers for AQM Routers Supporting TCP Flows, IEEE 793 Infocom, 2001. 795 [IMD01] G. Iannaccone, M. May, and C. Diot, Aggregate Traffic 796 Performance with Active Queue Management and Drop From Tail. 797 SIGCOMM Comput. Commun. Rev., 31(3):4-13, 2001. 799 [JD02] H. Jiang and C. Dovrolis, Passive Estimation of TCP Round- 800 trip Times, Computer Communication Review, 32(3), July 2002. 802 [MAF05] A. Medina, M. Allman, and A. Floyd. Measuring the Evolution 803 of Transport Protocols in the Internet. Computer Communication 804 Review, April 2005. 806 [NISTNet] NIST Net, URL "http://snad.ncsl.nist.gov/itg/nistnet/". 808 [PJD04] R. Prasad, M. Jain, and C. Dovrolis, On the Effectiveness of 809 Delay-Based Congestion Avoidance, PFLDnet 2004, February 2004. 811 [1] L. Qiu, Y. Zhang, and S. Keshav, Understanding the Performance 812 of Many TCP Flows, Comput. Networks, 37(3-4):277-306, 2001. 814 [RSB01] R. Riedi, S. Sarvotham, and R. Varaniuk, Connection-level 815 Analysis and Modeling of Network Traffic, SIGCOMM Internet 816 Measurement Workshop, 2001. 818 [RTW05] G. Raina, D. Towsley, and D. Wischik, Control Theory for 819 Buffer Sizing, CCR, July 2005. 821 [TG] Traffic Generators for Internet Traffic Web Page, URL 822 "http://www.icir.org/models/trafficgenerators.html". 824 [UA01] U. of Auckland, Auckland-vi trace data, June 2001. URL 825 "http://wans.cs.waikato.ac.nz/wand/wits/auck/6/". 827 [UW02] UW-Madison, Network Performance Statistics, October 2002. 828 URL "http://wwwstats.net.wisc.edu/". 830 [WM05] D. Wischik and N. McKeown, Buffer sizes for Core Routers, 831 CCR, July 2005. 833 [ZCS91] L. Zhang, S. Shenker, and D.D. Clark, Observations and 834 Dynamics of a Congestion Control Algorithm: the Effects of Two- 835 way Traffic, SIGCOMM 1991. 837 Editors' Addresses 839 Sally Floyd 840 ICSI Center for Internet Research 841 1947 Center Street, Suite 600 842 Berkeley, CA 94704 843 USA 845 Eddie Kohler 846 4531C Boelter Hall 847 UCLA Computer Science Department 848 Los Angeles, CA 90095 849 USA 851 Full Copyright Statement 853 Copyright (C) The Internet Society 2005. This document is subject 854 to the rights, licenses and restrictions contained in BCP 78, and 855 except as set forth therein, the authors retain all their rights. 857 This document and the information contained herein are provided on 858 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 859 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 860 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 861 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 862 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 863 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 865 Intellectual Property 867 The IETF takes no position regarding the validity or scope of any 868 Intellectual Property Rights or other rights that might be claimed 869 to pertain to the implementation or use of the technology described 870 in this document or the extent to which any license under such 871 rights might or might not be available; nor does it represent that 872 it has made any independent effort to identify any such rights. 873 Information on the procedures with respect to rights in RFC 874 documents can be found in BCP 78 and BCP 79. 876 Copies of IPR disclosures made to the IETF Secretariat and any 877 assurances of licenses to be made available, or the result of an 878 attempt made to obtain a general license or permission for the use 879 of such proprietary rights by implementers or users of this 880 specification can be obtained from the IETF on-line IPR repository 881 at http://www.ietf.org/ipr. 883 The IETF invites any interested party to bring to its attention any 884 copyrights, patents or patent applications, or other proprietary 885 rights that may cover technology that may be required to implement 886 this standard. Please address the information to the IETF at ietf- 887 ipr@ietf.org.