idnits 2.17.1 draft-irtf-tmrg-tools-00.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 680. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 691. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 698. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 704. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 672), 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 (13 September 2005) is 6801 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) == Unused Reference: 'FJ92' is defined on line 623, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 4 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-00.txt Editors 4 Expires: March 2006 13 September 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 March 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 1. Conventions 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC 2119]. 68 2. Introduction 70 This document discusses tools for the evaluation of simulation and 71 testbed scenarios used in research on Internet congestion control 72 mechanisms. These tools include but are not limited to measurement 73 tools; the tools discussed in this document are largely ways of 74 characterizing aggregate traffic on a link, or characterizing the 75 end-to-end path. One use of these tools is for understanding key 76 characteristics of test scenarios; many characteristics, such as the 77 distribution of per-packet round-trip times on the link, don't come 78 from a single input parameter but are determined by a range of 79 inputs. A second use of the tools is to compare key characteristics 80 of test scenarios with what is known of the same characteristics of 81 the past and current Internet, and with what can be conjectured 82 about these characteristics of future networks. This paper follows 83 the general approach from "Internet Research Needs Better Models" 84 [FK02]. 86 As an example of the power of tools for characterizing scenarios, a 87 great deal is known about the distribution of connection sizes on a 88 link, or equivalently, the distribution of per-packet sequence 89 numbers. It has been conjectured that a heavy-tailed distribution 90 of connection sizes is an invariant feature of Internet traffic. A 91 test scenario with mostly long-lived traffic, or with a mix with 92 only long-lived and very short flows, does not have a realistic 93 distribution of connection sizes, and can give unrealistic results 94 in simulations or experiments evaluating congestion control 95 mechanisms. For instance, the distribution of packet sequence 96 numbers makes clear the fraction of traffic on a link from medium- 97 sized connections, e.g., with packet sequence numbers from 100 to 98 1000. These medium-sized connections can slow-start up to a large 99 congestion window, possibly coming to an abrupt stop soon 100 afterwards, contributing significantly to the burstiness of the 101 aggregate traffic, and to the problems facing congestion control. 103 In the sections below we will discuss a number of tools for 104 describing and evaluating scenarios, show how these characteristics 105 can affect the results of research on congestion control mechanisms, 106 and summarize what is known about these characteristics in real- 107 world networks. 109 3. Tools 111 The tools or characteristics that we discuss are the following. 113 3.1. Characterizing Aggregate Traffic on a Link 115 o Distribution of per-packet round-trip times. 117 o Distribution of packet sequence numbers. 119 o Distribution of packet sizes. 121 o Distribution of peak flow rates. 123 o Distribution of transport protocols. 125 3.2. Characterizing an End-to-End Path 127 o Synchronization ratio. 129 o Drop rates as a function of packet size. 131 o Drop rates as a function of burst size. 133 o Degree of packet drops. 135 o Range of queueing delay. 137 3.3. Other Characteristics 139 o Congestion control mechanisms for background or competing 140 traffic. 142 o Characterization of congested links in terms of bandwidth and 143 typical levels of congestion (in terms of packet drop rates). 145 o Characterization of challenging lower layers in terms of 146 reordering, delay variation, packet corruption, and the like. 148 o Characterization of network changes affecting congestion, such as 149 routing changes or link outages. 151 Below we will discuss each characteristic in turn, giving the 152 definition, the factors determining that characteristic, the effect 153 on congestion control metrics, and what is known so far from 154 measurement studies in the Internet. 156 4. Distribution of per-packet round-trip times 158 Definition: The distribution of per-packet round-trip times on a 159 link is defined formally by assigning to each packet the most recent 160 round trip time measured for that end-to-end connection. In 161 practice, coarse-grained information is generally sufficient, even 162 though it has been shown that there is significant variability in 163 round-trip times within a TCP connection [AKSJ03], and it is 164 sufficient to assign to each packet the first round-trip time 165 measurement for that connection, or to assign the current round-trip 166 time estimate maintained by the TCP connection. 168 Determining factors: The distribution of per-packet round-trip times 169 on a link is determined by end-to-end propagation delays, by 170 queueing delays along end-to-end paths, and by the congestion 171 control mechanisms used by the traffic. For example, for a scenario 172 using TCP, TCP connections with smaller round-trip times will 173 receive a proportionally larger fraction of traffic than competing 174 TCP connections with larger round-trip times, all else being equal, 175 due to the dynamics of TCP favoring flows with smaller round-trip 176 times. This will generally shift the distribution of per-packet 177 RTTs lower relative to the distribution of per-connection RTTs, 178 since short-RTT connections will have more packets. 180 Effect on congestion control metrics: The distribution of per-packet 181 round-trip times on a link affects the burstiness of the aggregate 182 traffic, and therefore can affect congestion control performance in 183 a range of areas such as delay/throughput tradeoffs. The 184 distribution of per-packet round-trip times can also affect metrics 185 of fairness, degree of oscillations, and the like. For example, 186 long-term oscillations of queueing delay are more likely to occur in 187 scenarios with a narrow range of round-trip times [FK02]. 189 Measurements: The distribution of per-packet round-trip times for 190 TCP traffic on a link can be measured from a packet trace with the 191 passive TCP round-trip time estimator from Jiang and Dovrolis 192 [JD02]. [Add pointers to other estimators, such as ones mentioned 193 in JD02. Add a pointer to Mark Allman's loss detection tool.] 194 Their paper shows the distribution of per-packet round-trip times 195 for TCP packets for a number of different links. For the links 196 measured, the percent of packets with round-trip times at most 197 100 ms ranged from 30% to 80%, and the percent of packets with 198 round-trip times at most 200 ms ranged from 55% to 90%, depending on 199 the link. 201 In the NS simulator, the distribution of per-packet round-trip times 202 for TCP packets on a link can be reported by the queue monitor, 203 using TCP's estimated round-trip time added to packet headers. This 204 is illustrated in the validation test "./test-all-simple stats3" in 205 the directory tcl/test. 207 Scenarios: [FK02] shows a relatively simple scenario, with a 208 dumbbell topology with four access links on each end, that gives a 209 fairly realistic range of round-trip times. [Look for the other 210 citations to add.] 212 5. Distribution of packet sequence numbers 214 Definition: The distribution of packet sequence numbers on a link is 215 defined by giving each packet a sequence number, where the first 216 packet in a connection has sequence number 1, the second packet has 217 sequence number 2, and so on. The distribution of packet sequence 218 numbers can be derived in a straightforward manner from the 219 distribution of connection sizes, and vice versa; however, the 220 distribution of connection sizes is more suited for traffic 221 generators, and the distribution of packet sequence numbers is more 222 suited for measuring and illustrating the packets actually seen on a 223 link over a fixed interval of time. There has been a considerably 224 body of research over the last ten years on the heavy-tailed 225 distribution of connection sizes for traffic on the Internet. 226 [CBC95] [Add citations.] 228 Determining factors: The distribution of connection sizes is largely 229 determined by the traffic generators used in a scenario. For 230 example, is there a single traffic generator characterized by a 231 distribution of connection sizes? A mix of long-lived and web 232 traffic, with the web traffic characterized by a distribution of 233 connection sizes? Or something else? 235 Effect on congestion control metrics: The distribution of packet 236 sequence numbers affects the burstiness of aggregate traffic on a 237 link, thereby affecting all congestion control metrics for which 238 this is a factor. As an example, [FK02] illustrates that the 239 traffic mix can affect the queue dynamics on a congested link. 240 [Find more to cite, about the effect of the distribution of packet 241 sequence numbers on congestion control metrics.] 243 [Add a paragraph about the impact of medium-size flows.] 245 [Add a paragraph about the impact of flows starting and stopping.] 247 [Add a warning about scenarios that use only long-lived flows, or a 248 mix of long-lived and very short flows.] 250 Measurements: [Cite some of the literature.] 252 Traffic generators: Some of the available traffic generators are 253 listed on the web site for "Traffic Generators for Internet Traffic" 254 [TG]. This includes pointers to traffic generators for peer-to-peer 255 traffic, traffic from online games, and traffic from Distributed 256 Denial of Service (DDoS) attacks. 258 In the NS simulator, the distribution of packet sequence numbers for 259 TCP packets on a link can be reported by the queue monitor at a 260 router. This is illustrated in the validation test "./test-all- 261 simple stats3" in the directory tcl/test. 263 6. The Distribution of Packet Sizes 265 Definition: The distribution of packet sizes is defined in a 266 straightforward way, using packet sizes in bytes. 268 Determining factors: The distribution of packet sizes is determined 269 by the traffic mix, the path MTUs, and by the packet sizes used by 270 the transport-level senders. 272 The distribution of packet sizes on a link is also determined by the 273 mix of forward-path TCP traffic and reverse-path TCP traffic in that 274 scenario, for a scenario characterized by a `forward path' (e.g., 275 left to right on a particular link) and a `reverse path' (e.g., 276 right to left on the same link). For such a scenario, the forward- 277 path TCP traffic contributes data packets to the forward link and 278 acknowledgment packets to the reverse link, while the reverse-path 279 TCP traffic contributes small acknowledgment packets to the forward 280 link. The ratio between TCP data and TCP ACK packets on a link can 281 be used as some indication of the ratio between forward-path and 282 reverse-path TCP traffic. 284 Effect on congestion control metrics: The distribution of packet 285 sizes on a link is an indicator of the ratio of forward-path and 286 reverse-path TCP traffic in that network. The amount of reverse- 287 path traffic determines the loss and queueing delay experienced by 288 acknowledgement packets on the reverse path, significantly affecting 289 the burstiness of the aggregate traffic on the forward path. [Add 290 citations.] [In what other ways does the distribution of packet 291 sizes affect congestion control metrics?] 293 Measurements: There has been a wealth of measurements over time on 294 the packet size distribution of traffic [A00], [HMTG01]. These 295 measurements are generally consistent with a model of roughly 10% of 296 the TCP connections using an MSS of roughly 500 bytes, and with the 297 other 90% of TCP connections using an MSS of 1460 bytes. 299 7. The Distribution of Per-Packet Peak Flow Rates 301 Definition: The distribution of peak flow rates is defined by 302 assigning to each packet the peak sending rate in bytes per second 303 of that connection, where the peak sending rate is defined over 304 0.1-second intervals. The distribution of peak flow rates gives 305 some indication of the ratio of "alpha" and "beta" traffic on a 306 link, where alpha traffic on a congested link is defined as traffic 307 with that link at the main bottleneck, while the beta traffic on the 308 link has a primary bottleneck elsewhere along its path [RSB01]. 310 Determining factors: The distribution of peak flow rates is 311 determined by flows with bottlenecks elsewhere along their end-to- 312 end path, e.g., flows with low-bandwidth access links. The 313 distribution of peak flow rates is also affected by applications 314 with limited sending rates. 316 Effect on congestion control metrics: The distribution of peak flow 317 rates affects the burstiness of aggregate traffic, with low-peak- 318 rate traffic decreasing the aggregate burstiness, and adding to the 319 traffic's tractability. 321 Measurements: [RSB01]. The distribution of peak rates can be 322 expected to change over time, as there is an increasing number of 323 high-bandwidth access links to the home, and of high-bandwidth 324 Ethernet links at work and at other institutions. 326 Simulators: [For NS, add a pointer to the DelayBox, 327 "http://dirt.cs.unc.edu/delaybox/", for more easily simulating low- 328 bandwidth access links for flows.] 330 8. The Distribution of Transport Protocols. 332 Definition: The distribution of transport protocols on a congested 333 link is straightforward, with each packet given its associated 334 transport protocol (e.g., TCP, UDP). The distribution is often 335 given both in terms of packets and in terms of bytes. 337 For UDP packets, it might be more helpful to classify them in terms 338 of the port number, or the assumed application (e.g., DNS, RIP, 339 games, Windows Media, RealAudio, RealVideo, etc.) [MAWI]). Other 340 traffic includes ICMP, IPSEC, and the like. In the future there 341 could be traffic from SCTP, DCCP, or from other transport protocols. 343 Effect on congestion control metrics: The distribution of transport 344 protocols affects metrics relating to the effectiveness of AQM 345 mechanisms on a link. 347 Measurements: In the past, TCP traffic has typically consisted of 348 90% to 95% of the bytes on a link [UW02], [UA01]. [Get updated 349 citations for this.] Measurement studies show that TCP traffic from 350 web servers almost always uses conformant TCP congestion control 351 procedures [MAF05]. 353 9. The Synchronization Ratio 355 Definition: The synchronization ratio is defined as the degree of 356 synchronization of loss events between two TCP flows on the same 357 path. Thus, the synchronization ratio is defined as a 358 characteristic of an end-to-end path. When one TCP flow of a pair 359 has a loss event, the synchronization ratio is given by the fraction 360 of those loss events for which the second flow has a loss event 361 within one round-trip time. Each connection in a flow pair has a 362 separate synchronization ratio, and the overall synchronization 363 ratio of the pair of flows is the higher of the two ratios. When 364 measuring the synchronization ratio, it is preferable to start the 365 two TCP flows at slightly different times, with large receive 366 windows. 368 Determining factors: The synchronization ratio is determined largely 369 by the traffic mix on the congested link, and by the AQM mechanism 370 (or lack of AQM mechanism). 372 Different types of TCP flows are also likely to have different 373 synchronization measures. E.g., Two HighSpeed TCP flows might have 374 higher synchronization measures that two Standard TCP flows on the 375 same path, because of their more aggressive window increase rates. 377 Effect on congestion control metrics: The synchronization ratio 378 affects convergence times for high-bandwidth TCPs. Convergence 379 times are known to be poor for some high-bandwidth protocols in 380 environments with high levels of synchronization. [Cite the papers 381 by Leith and Shorten.] However, it is not clear if these 382 environments with high levels of synchronization are realistic. 384 Measurements: Grenville Armitage and Qiang Fu have performed initial 385 experiments of synchronization in the Internet, using Standard TCP 386 flows, and have found very low levels of synchronization. 388 [Appenzeller et al, Sizing Router Buffers, reports that 389 synchronization is rare as the number of competing flows increases. 390 Kevin Jeffay has some results on synchronization also.] 392 Needed: We need measurements of the synchronization ratio for flows 393 that use high-bandwidth protocols over high-bandwidth paths, given 394 typical levels of competing traffic and with typical queuing 395 mechanisms at routers (whatever these are), to see if there are 396 higher levels of synchronization with high-bandwidth protocols such 397 as HighSpeed TCP, Fast TCP, and the like, which are more aggressive 398 than Standard TCP. The assumption would be that in many 399 environments, high-bandwidth protocols have higher levels of 400 synchronization than flows using Standard TCP. 402 10. Drop or Mark Rates as a Function of Packet Size 404 Definition: Drop rates as a function of packet size are defined by 405 the actual drop rates for different packets on an end-to-end path or 406 on a congested link over a particular time interval. In some cases, 407 e.g., Drop-Tail queues in units of packets, general statements can 408 be made; e.g., that large and small packets will experience the same 409 packet drop rates. However, in other cases, e.g., Drop-Tail queues 410 in units of bytes, no such general statement can be made, and the 411 drop rate as a function of packet size will be determined in part by 412 the traffic mix at the congested link at that point of time. 414 Determining factors: The drop rate as a function of packet size is 415 determined in part by the queue architecture. E.g., is the Drop- 416 Tail queue in units of packets, of bytes, of 60-byte buffers, or of 417 a mix of buffer sizes? Is the AQM mechanism in packet mode, 418 dropping each packet with the same probability, or in byte mode, 419 with the probability of dropping or marking a packet being 420 proportional to the packet size in bytes. 422 The effect of packet size on drop rate would also be affected by the 423 presence of preferential scheduling for small packets, or by 424 differential scheduling for packets from different flows (e.g., per- 425 flow scheduling, or differential scheduling for UDP and TCP 426 traffic). 428 In many environments, the drop rate as a function of packet size 429 will be heavily affected by the traffic mix at a particular time. 430 For example, is the traffic mix dominated by large packets, or by 431 smaller ones? In some cases, the overall packet drop rate could 432 also affect the relative drop rates for different packet sizes. 434 Effect on congestion control metrics: The drop rate as a function of 435 packet size has a significant effect on the performance of 436 congestion control for VoIP and other small-packet flows. 437 [Citation: "TFRC for Voice: the VoIP Variant", draft-ietf-dccp-tfrc- 438 voip-02.txt, and earlier papers.] The drop rate as a function of 439 packet size also has an effect on TCP performance, as it affects the 440 drop rates for TCP's SYN and ACK packets. [Citation: Jeffay and 441 others.] 443 Measurements: We need measurements of the drop rate as a function of 444 packet size over a wide range of paths, or for a wide range of 445 congested links. For tests of relative drop rates on end-to-end 446 packets, one possibility would be to run successive TCP connections 447 with 200-byte, 512-byte, and 1460-byte packets, and to compare the 448 packet drop rates. The ideal test would include running TCP 449 connections on the reverse path, to measure the drop rates for the 450 small ACK packets on the forward path. It would also be useful to 451 characterize the difference in drop rates for 200-byte TCP packets 452 and 200-byte UDP packets, even though some of this difference could 453 be due to the relative burstiness of the different connections. 455 Ping experiments could also be used to get measurements of drop 456 rates as a function size, but it would be necessary to make sure 457 that the ping sending rates were adjusted to be TCP-friendly. 459 [Cite the known literature on drop rates as a function of packet 460 size.] 462 Our conjecture is that there is a wide range of behaviors for this 463 characteristic in the real world. Routers include Drop-Tail queues 464 in packets, bytes, and buffer sizes in between; these will have 465 quite different drop rates as a function of packet size. Some 466 routers include RED in byte mode (the default for RED in Linux) and 467 some have RED in packet mode (Cisco, I believe). This also affects 468 drop rates as a function of packet size. 470 Some routers on congested access links use per-flow scheduling. In 471 this case, does the per-flow scheduling have the goal of fairness in 472 *bytes* per second or in *packets* per second? What effect does the 473 per-flow scheduling have on the drop rate as a function of packet 474 size, for packets in different flows (e.g., a small-packet VoIP flow 475 competing against a large-packet TCP flow) or for packets within the 476 same flow (small ACK packets and large data packets on a two-way TCP 477 connection). 479 11. Drop Rates as a Function of Burst Size. 481 Definition: Burst-tolerance, or drop rates as a function of burst 482 size, can be defined in terms of an end-to-end path, or in terms of 483 aggregate traffic on a congested link. 485 The burst-tolerance of an end-to-end path is defined in terms of 486 connections with different degrees of burstiness within a round-trip 487 time. When packets are sent in bursts of N packets, does the drop 488 rate vary as a function of N? For example, if the TCP sender sends 489 small bursts of K packets, for K less than the congestion window, 490 how does the size of K affect the loss rate? Similarly, for a ping 491 tool sending pings at a certain rate in packets per second, one 492 could see how the clustering of the ping packets in clusters of size 493 K affects the packet drop rate. As always with such ping 494 experiments, it would be important to adjust the sending rate to 495 maintain a longer-term sending rate that was TCP-friendly. 497 Determining factors: The burst-tolerance is determined largely by 498 the AQM mechanisms for the congested routers on a path, and by the 499 traffic mix. For a Drop-Tail queue with only a small number of 500 competing flows, the burst-tolerance is likely to be low, and for 501 AQM mechanisms where the packet drop rate is a function of the 502 average queue size rather than the instantaneous queue size, the 503 burst tolerance should be quite high. 505 Effect on conjestion control metrics: The burst-tolerance of the 506 path or congested link can affect fairness between competing flows 507 with different round-trip times; for example, Standard TCP flows 508 with longer round-trip times are likely to have a more bursty 509 arrival pattern at the congested link that that of Standard TCP 510 flows with shorter round-trip times. As a result, in environment 511 with low burst tolerance (e.g., scenarios with Drop-Tail queues), 512 longer-round-trip-time TCP connections can see higher packet drop 513 rates than other TCP connections, and receive an even smaller 514 fraction of the link bandwidth than they would otherwise. 515 [FJ92](Section 3.2). We note that some TCP traffic is inherently 516 bursty, e.g., Standard TCP without rate-based pacing, particularly 517 in the presence of dropped ACK packets or of ACK compression. The 518 burst-tolerance of a router can also affect the delay-throughput 519 tradeoffs and packet drop rates of the path or of the congested 520 link. 522 Measurements: One could measure the burst-tolerance of an end-to-end 523 path by running successive TCP connections, forcing bursts of size 524 at least K by dropping an appropriate fraction of the ACK packets to 525 the TCP receiver. Alternately, if one had control of the TCP 526 sender, one could modify the TCP sender to send bursts of K packets 527 when the congestion window was K or more segments. 529 [Look at Crovella's paper on loss pairs.] 531 [Look at: M. Allman and E. Blanton, "Notes on Burst Mitigation for 532 Transport Protocols", ACM Computer Communication Review, vol. 35(2), 533 (2005).] 535 Making inferences about the AQM mechanism for the congested router 536 on an end-to-end path: One potential use of measurement tools for 537 determining the burst-tolerance of an end-to-end path would be to 538 make inferences about the presence or absence of an AQM mechanism at 539 the congested link or links. As a simple test, one could run a TCP 540 connection until the connection comes out of slow-start. If the 541 receive window of the TCP connection was sufficiently high that the 542 connection exited slow-start with packet drops or marks instead of 543 because of the limitation of the receive window, one could record 544 the congestion window at the end of slow-start, and the number of 545 packets dropped from this window. A high packet drop rate might be 546 more typical of a Drop-Tail queue with small-scale statistical 547 multiplexing on the congested link, and a single packet drop coming 548 out of slow-start would suggest an AQM mechanism at the congested 549 link. 551 The synchronization measure could also add information about the 552 likely presence or absence of AQM on the congested link(s) of an 553 end-to-end path, with paths with higher levels of synchronization 554 being more likely to have Drop-Tail queues with small-scale 555 statistical multiplexing on the congested link(s). 557 [Cite the relevant literature about tools for determining the AQM 558 mechanism on an end-to-end path.] 560 12. Congestion Control Mechanisms for Background or Competing Traffic 562 Effect on congestion control metrics: Please don't evaluate AQM 563 mechanisms by using Reno TCP, or evaluate new transport protocols by 564 comparing them with the performance of Reno TCP! For an 565 explanation, see [FK02](Section 3.4). 567 Measurements: See [MAF05]. 569 13. Characterization of Congested Links in Terms of Bandwidth and 570 Typical Levels of Congestion 572 [Pointers to the current state of our knowledge.] 574 14. Characterization of Challenging Lower Layers. 576 [This will just be a short set of pointers to the relevant 577 literature, which is quite extensive.] 579 15. Characterization of Network Changes Affecting Congestion 581 [Pointers to the current state of our knowledge.] 583 16. Using the Tools Presented in this Document 585 [To be done.] 587 17. Related Work 589 [Cite "On the Effective Evaluation of TCP" by Allman and Falk.] 591 18. Conclusions 593 [To be done.] 595 19. Security Considerations 597 There are no security considerations in this document. 599 20. IANA Considerations 601 There are no IANA considerations in this document. 603 21. Acknowledgements 605 Informative References 607 [RFC 2119] S. Bradner. Key Words For Use in RFCs to Indicate 608 Requirement Levels. RFC 2119. 610 [MAWI] M.W. Group, Mawi working group traffic archive, URL 611 "http://tracer.csl.sony.jp/mawi/". 613 [AKSJ03] J. Aikat, J. Kaur, F.D. Smith, and K. Jeffay, Variability 614 in TCP Roundtrip Times, ACM SIGCOMM Internet Measurement 615 Conference, Maimi, FL, October 2003, pp. 279-284. 617 [A00] M. Allman, A Web Server's View of the Transport Layer, 618 Computer Communication Review, 30(5), October 200. 620 [CBC95] C. Cunha, A. Bestavros, and M. Crovella, "Characteristics of 621 WWW Client-based Traces", BU Technical Report BUCS-95-010, 1995. 623 [FJ92] S. Floyd and V. Jacobson, On Traffic Phase Effects in Packet- 624 Switched Gateways, Internetworking: Research and Experience, V.3 625 N.3, September 1992, p.115-156. 627 [FK02] S. Floyd and E. Kohler, Internet Research Needs Better 628 Models, Hotnets-I, October 2002. 630 [HMTG01] C. Hollot, V. Misra, D. Towsley, and W. Gong, On Designing 631 Improved Controllers for AQM Routers Supporting TCP Flows, IEEE 632 Infocom, 2001. 634 [JD02] H. Jiang and C. Dovrolis, Passive Estimation of TCP Round- 635 trip Times, Computer Communication Review, 32(3), July 2002. 637 [MAF05] A. Medina, M. Allman, and A. Floyd. Measuring the Evolution 638 of Transport Protocols in the Internet. Computer Communication 639 Review, April 2005. 641 [RSB01] R. Riedi, S. Sarvotham, and R. Varaniuk, Connection-level 642 Analysis and Modeling of Network Traffic, SIGCOMM Internet 643 Measurement Workshop, 2001. 645 [TG] Traffic Generators for Internet Traffic Web Page, URL 646 "http://www.icir.org/models/trafficgenerators.html". 648 [UA01] U. of Auckland, Auckland-vi trace data, June 2001. URL 649 "http://wans.cs.waikato.ac.nz/wand/wits/auck/6/". 651 [UW02] UW-Madison, Network Performance Statistics, October 2002. 652 URL "http://wwwstats.net.wisc.edu/". 654 Editors' Addresses 656 Sally Floyd 657 ICSI Center for Internet Research 658 1947 Center Street, Suite 600 659 Berkeley, CA 94704 660 USA 662 Eddie Kohler 663 4531C Boelter Hall 664 UCLA Computer Science Department 665 Los Angeles, CA 90095 666 USA 668 Full Copyright Statement 670 Copyright (C) The Internet Society 2005. This document is subject 671 to the rights, licenses and restrictions contained in BCP 78, and 672 except as set forth therein, the authors retain all their rights. 674 This document and the information contained herein are provided on 675 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 676 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 677 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 678 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 679 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 680 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 682 Intellectual Property 684 The IETF takes no position regarding the validity or scope of any 685 Intellectual Property Rights or other rights that might be claimed 686 to pertain to the implementation or use of the technology described 687 in this document or the extent to which any license under such 688 rights might or might not be available; nor does it represent that 689 it has made any independent effort to identify any such rights. 690 Information on the procedures with respect to rights in RFC 691 documents can be found in BCP 78 and BCP 79. 693 Copies of IPR disclosures made to the IETF Secretariat and any 694 assurances of licenses to be made available, or the result of an 695 attempt made to obtain a general license or permission for the use 696 of such proprietary rights by implementers or users of this 697 specification can be obtained from the IETF on-line IPR repository 698 at http://www.ietf.org/ipr. 700 The IETF invites any interested party to bring to its attention any 701 copyrights, patents or patent applications, or other proprietary 702 rights that may cover technology that may be required to implement 703 this standard. Please address the information to the IETF at ietf- 704 ipr@ietf.org.