idnits 2.17.1 draft-irtf-iccrg-welzl-congestion-control-open-research-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Too long document name: The document name (without revision number), 'draft-irtf-iccrg-welzl-congestion-control-open-research', is 55 characters long, but may be at most 50 characters Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 01, 2010) is 4987 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 1323 (Obsoleted by RFC 7323) -- Obsolete informational reference (is this intentional?): RFC 2581 (Obsoleted by RFC 5681) -- Obsolete informational reference (is this intentional?): RFC 2861 (Obsoleted by RFC 7661) -- Obsolete informational reference (is this intentional?): RFC 2988 (Obsoleted by RFC 6298) -- Obsolete informational reference (is this intentional?): RFC 3517 (Obsoleted by RFC 6675) -- Obsolete informational reference (is this intentional?): RFC 3662 (Obsoleted by RFC 8622) -- Obsolete informational reference (is this intentional?): RFC 4614 (Obsoleted by RFC 7414) -- Obsolete informational reference (is this intentional?): RFC 5405 (Obsoleted by RFC 8085) -- Duplicate reference: RFC2581, mentioned in 'RFC5681', was also mentioned in 'RFC2581'. -- Obsolete informational reference (is this intentional?): RFC 2581 (ref. 'RFC5681') (Obsoleted by RFC 5681) == Outdated reference: A later version (-04) exists of draft-sarolahti-tsvwg-tcp-frto-02 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Dimitri Papadimitriou, Editor 3 Internet Draft Alcatel-Lucent 4 Intended status: Informational Michael Welzl 5 Expires: March 02, 2011 University of Oslo 6 Michael Scharf 7 University of Stuttgart 8 Bob Briscoe 9 BT & UCL 11 September 01, 2010 13 Open Research Issues in Internet Congestion Control 15 draft-irtf-iccrg-welzl-congestion-control-open-research-08.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on March 02, 2011. 40 Abstract 42 This document describes some of the open problems in Internet 43 congestion control that are known today. This includes several new 44 challenges that are becoming important as the network grows, as well 45 as some issues that have been known for many years. These challenges 46 are generally considered to be open research topics that may require 47 more study or application of innovative techniques before Internet- 48 scale solutions can be confidently engineered and deployed. This 49 document represents the work and the consensus of the ICCRG. 51 Open Research Issues in Internet Congestion Control Sep. 2010 53 Table of Contents 55 1. Introduction...................................................3 56 2. Global Challenges..............................................4 57 2.1 Heterogeneity..............................................4 58 2.2 Stability..................................................6 59 2.3 Fairness...................................................7 60 3. Detailed Challenges............................................9 61 3.1 Challenge 1: Network Support...............................9 62 3.1.1 Performance and Robustness.........................12 63 3.1.2 Granularity of network component functions.........13 64 3.1.3 Information Acquisition............................14 65 3.1.4 Feedback signaling.................................15 66 3.2 Challenge 2: Corruption Loss..............................15 67 3.3 Challenge 3: Packet Size..................................17 68 3.4 Challenge 4: Flow Startup.................................21 69 3.5 Challenge 5: Multi-domain Congestion Control..............23 70 3.5.1 Multi-domain Transport of Explicit Congestion 71 Notification.............................................23 72 3.5.2 Multi-domain Exchange of Topology or Explicit Rate 73 Information..............................................24 74 3.5.3 Multi-domain Pseudowires...........................25 75 3.6 Challenge 6: Precedence for Elastic Traffic...............26 76 3.7 Challenge 7: Misbehaving Senders and Receivers............28 77 3.8 Other Challenges..........................................29 78 3.8.1 RTT Estimation.....................................29 79 3.8.2 Malfunctioning Devices.............................31 80 3.8.3 Dependence on RTT..................................32 81 3.8.4 Congestion Control in Multi-layered Networks.......32 82 3.8.5 Multipath End-to-end Congestion Control and Traffic 83 Engineering..............................................33 84 3.8.6 ALGs and Middleboxes...............................33 85 4. Security Considerations.......................................34 86 5. IANA Considerations...........................................35 87 6. References....................................................36 88 6.2 Informative References....................................36 89 7. Acknowledgments...............................................46 90 8. Author's Addresses............................................46 91 9. Contributors..................................................46 92 Copyright Statement..............................................47 94 Open Research Issues in Internet Congestion Control Sep. 2010 96 1. Introduction 98 This document, result of the ICCRG Research Group, describes some 99 of the open research topics in the domain of Internet congestion 100 control that are known today. We begin by reviewing some proposed 101 definitions of congestion and congestion control based on current 102 understandings. 104 Congestion can be defined as a state or condition that occurs when 105 network resources are overloaded resulting in impairments for network 106 users as objectively measured by the probability of loss and/or of 107 delay. The overload results in the reduction of utility in networks 108 that support both spatial and temporal multiplexing, but no 109 reservation [Keshav07]. Congestion control is a (typically 110 distributed) algorithm to share network resources among competing 111 traffic sources. 113 Two components of distributed congestion control have been defined in 114 the context of primal-dual modeling [Kelly98]. Primal congestion 115 control refers to the algorithm executed by the traffic sources for 116 controlling their sending rates or window sizes. This is normally a 117 closed-loop control, where this operation depends on feedback. TCP 118 algorithms fall in this category. Dual congestion control is 119 implemented by the routers through gathering information about the 120 traffic traversing them. A dual congestion control algorithm updates, 121 implicitly or explicitly, a congestion measure or congestion rate and 122 sends it back, implicitly or explicitly, to the traffic sources that 123 use that link. Queue management algorithms such as Random Early 124 Detection (RED) [Floyd93] or Random Exponential Marking (REM) [Ath01] 125 fall into the "dual" category. 127 Congestion control provides for a fundamental set of mechanisms for 128 maintaining the stability and efficiency of the Internet. Congestion 129 control has been associated with TCP since Van Jacobson's work in 130 1988, but there is also congestion control outside of TCP (e.g. for 131 real-time multimedia applications, multicast, and router-based 132 mechanisms) [RFC5783]. The Van Jacobson end-to-end congestion 133 control algorithms [Jacobson88] [RFC2581] [RFC5681] are used by the 134 Internet transport protocol TCP [RFC4614]. They have been proven to 135 be highly successful over many years but have begun to reach their 136 limits, as the heterogeneity of both the data link and physical 137 layer and applications are pulling TCP congestion control beyond its 138 natural operating regime, because it performs poorly as the bandwidth 139 or delay increases. A side effect of these deficiencies is that an 140 increasing share of hosts use non-standardized congestion control 141 enhancements (for instance, many Linux distributions have been 142 shipped with "CUBIC" [Ha08] as the default TCP congestion control 143 mechanism). 145 Open Research Issues in Internet Congestion Control Sep. 2010 147 While the original Van Jacobson algorithm requires no congestion- 148 related state in routers, more recent modifications have departed 149 from the strict application of the end-to-end principle [Saltzer84] 150 in order to avoid congestion collapse. Active Queue Management (AQM) 151 in routers, e.g., RED and some of its variants such as Adaptive RED 152 (ARED), improves performance by keeping queues small (implicit 153 feedback via dropped packets), while Explicit Congestion Notification 154 (ECN) [Floyd94] [RFC3168] passes one bit of congestion information 155 back to senders when an AQM would normally drop a packet. It is to be 156 noted that other variants of RED built on AQM such as Weighted RED 157 (WRED), and RED with In/Out (RIO) [Clark98] for quality enforcement 158 whereas Stabilized RED (SRED), and XCHOKe [Pan00] are flow policers. 159 In [Bonald00], authors analytically evaluated RED performance. 161 These measures do improve performance, but there is a limit to how 162 much can be accomplished without more information from routers. The 163 requirement of extreme scalability together with robustness has been 164 a difficult hurdle to accelerating information flow. Primal-Dual 165 TCP/AQM distributed algorithm stability and equilibrium properties 166 have been extensively studied (cf. [Low02], [Low03.1], [Low03.2], 167 [Kelly98], [Kelly05]). 169 Congestion control includes many new challenges that are becoming 170 important as the network grows in addition to the issues that have 171 been known for many years. These are generally considered to be open 172 research topics that may require more study or application of 173 innovative techniques before Internet-scale solutions can be 174 confidently engineered and deployed. In what follows, an overview of 175 some of these challenges is given. 177 2. Global Challenges 179 This section describes the global challenges to be addressed in the 180 domain of Internet congestion control. 182 2.1 Heterogeneity 184 The Internet encompasses a large variety of heterogeneous IP networks 185 that are realized by a multitude of technologies, which result in a 186 tremendous variety of link and path characteristics: capacity can be 187 either scarce in very slow speed radio links (several kbps), or there 188 may be an abundant supply in high-speed optical links (several 189 gigabit per second). Concerning latency, scenarios range from local 190 interconnects (much less than a millisecond) to certain wireless and 191 satellite links with very large latencies up to or over a second). 192 Even higher latencies can occur in space communication. As a 193 consequence, both the available bandwidth and the end-to-end delay in 194 the Internet may vary over many orders of magnitude, and it is likely 195 that the range of parameters will further increase in future. 197 Open Research Issues in Internet Congestion Control Sep. 2010 199 Additionally, neither the available bandwidth nor the end-to-end 200 delay is constant. At the IP layer, competing cross-traffic, traffic 201 management in routers, and dynamic routing can result in sudden 202 changes of the characteristics of an end-to-end path. Additional 203 dynamics can be caused by link layer mechanisms, such as shared media 204 access (e.g., in wireless networks), changes of links due to mobility 205 (horizontal/vertical handovers), topology modifications (e. g., in 206 ad-hoc or meshed networks), link layer error correction and dynamic 207 bandwidth provisioning schemes. From this, it follows that path 208 characteristics can be subject to substantial changes within short 209 time frames. 211 Congestion control algorithms have to deal with this variety in an 212 efficient and stable way. The congestion control principles 213 introduced by Van Jacobson assume a rather static scenario and 214 implicitly target configurations where the bandwidth-delay product is 215 of the order of some dozens of packets at most. While these 216 principles have proved to work in the Internet for almost two 217 decades, much larger bandwidth-delay products and increased dynamics 218 challenge them more and more. There are many situations where today's 219 congestion control algorithms react in a suboptimal way, resulting 220 among other things in low resource utilization, and non-optimal 221 congestion avoidance. 223 This has resulted in a multitude of new proposals for congestion 224 control algorithms. For instance, since the Additive Increase 225 Multiplicative Decrease (AIMD) behavior of TCP is too conservative in 226 practical environments when the congestion window is large, several 227 high-speed congestion control extensions have been developed. 228 However, these new algorithms may be less robust or starve legacy 229 flows in certain situations for which they have not been designed. At 230 the time of writing, there is no common agreement in the IETF on 231 which algorithm(s) and protocol(s) to choose. 233 It is always possible to tune congestion control parameters based on 234 some knowledge of the environment and the application scenario. 235 However, the interaction between multiple congestion control 236 techniques interacting with each other is not yet well understood. 237 The fundamental challenge is whether it is possible to define one 238 congestion control mechanism that operates reasonably well in a 239 whole range of scenarios that exist in the Internet. Hence, it is an 240 important research question how new Internet congestion control 241 mechanisms would have to be designed, which maximum degree of 242 dynamics they can efficiently handle, and whether they can keep the 243 generality of the existing end-to-end solutions. 245 Some improvements to congestion control could be realized by simple 246 changes of single functions in end-system or optimizations of network 247 components. However, new mechanism(s) might also require a 249 Open Research Issues in Internet Congestion Control Sep. 2010 251 fundamental redesign of the overall network architecture, and they 252 may even affect the design of Internet applications. This can imply 253 significant interoperability and backward compatibility challenges 254 and/or create network accessibility obstacles. In particular, 255 networks and/or applications that do not use or support a new 256 congestion control mechanism could be penalized by a significantly 257 worse performance compared to what they would get if everybody used 258 the existing mechanisms (cf. the discussion on fairness in section 259 2.3). [RFC5033] defines several criteria to evaluate the 260 appropriateness of a new congestion control mechanism. However, a key 261 issue is how much performance deterioration is acceptable for 262 "legacy" applications. This tradeoff between performance and cost has 263 to be very carefully examined for all new congestion control schemes. 265 2.2 Stability 267 Control theory is a mathematical tool for describing dynamic systems. 268 It lends itself to modeling congestion control - TCP is a perfect 269 example of a typical "closed loop" system that can be described in 270 control theoretic terms. However, control theory has had to be 271 extended to model the interactions between multiple control loops in 272 a network. In control theory, there is a mathematically defined 273 notion of system stability. In a stable system, for any bounded input 274 over any amount of time, the output will also be bounded. For 275 congestion control, what is actually meant by global stability is 276 typically asymptotic stability: a mechanism should converge to a 277 certain state irrespective of the initial state of the network. Local 278 stability means that if the system is perturbed from its stable state 279 it will quickly return towards the locally stable state. 281 Some fundamental facts known from control theory are useful as 282 guidelines when designing a congestion control mechanism. For 283 instance, a controller should only be fed a system state that 284 reflects its output. A (low-pass) filter function should be used in 285 order to pass only states to the controller that are expected to last 286 long enough for its action to be meaningful [Jain88]. Action should 287 be carried out whenever such feedback arrives, as it is a fundamental 288 principle of control that the control frequency should ideally be 289 equal to the feedback frequency. Reacting faster leads to 290 oscillations and instability while reacting slower makes the system 291 tardy [Jain90]. 293 Control theoretic modeling of a realistic network can be quite 294 difficult, especially when taking distinct packet sizes and 295 heterogeneous RTTs into account. It has therefore become common 296 practice to model simpler cases and to leave the more complicated 297 (realistic) situations for simulations. Clearly, if a mechanism is 298 not stable in a simple scenario, it is generally useless; this method 299 therefore helps to eliminate faulty congestion control candidates at 301 Open Research Issues in Internet Congestion Control Sep. 2010 303 an early stage. However, a mechanism that is found to be stable in 304 simulations can still note be safely deployed in real networks, since 305 simulation scenarios make simplifying assumptions. 307 TCP stability can be attributed to two key aspects which were 308 introduced in [Jacobson88]: the AIMD control law during congestion 309 avoidance, which is based on a simple, vector based analysis of two 310 controllers sharing one resource with synchronous RTTs [Chiu89], and 311 the "conservation of packets principle", which, once the control has 312 reached "steady state", tries to maintain an equal amount of packets 313 in flight at any time by only sending a packet into the network when 314 a packet has left the network (as indicated by an ACK arriving at the 315 sender). The latter aspect has guided many decisions regarding 316 changes that were made to TCP over the years. 318 The reasoning in [Jacobson88] assumes all senders to be acting at the 319 same time. The stability of TCP under more realistic network 320 conditions has been investigated in a large number of ensuing works, 321 leading to no clear conclusion that TCP would also be asymptotically 322 stable under arbitrary network conditions. On the other hand, 323 research has concluded that stability can be assured with constraints 324 on dynamics that are less stringent than the "conservation of packets 325 principle". From control theory, only rate increase (not the target 326 rate) needs to be inversely proportional to RTT (whereas window-based 327 control converges on a target rate inversely proportional to RTT). 328 A congestion control mechanism can therefore converge on a rate that 329 is independent of RTT as long as its dynamics depend on RTT (e.g. 330 FAST TCP [Jin04]). 332 In the stability analysis of TCP and of these more modern controls, 333 the impact of Slow Start on stability (which can be significant as 334 short-lived HTTP flows often never leave this phase) is not entirely 335 clear. 337 2.3 Fairness 339 Recently, the way the Internet community reasons about fairness has 340 been called into deep questioning [Bri07]. Much of the community has 341 taken fairness to mean approximate equality between the rates of 342 flows (flow rate fairness) that experience equivalent path congestion 343 as with TCP [RFC2581],[RFC5681] and TFRC [RFC5348]. [RFC3714] depicts 344 the resulting situation as "The Amorphous Problem of Fairness". 346 A parallel tradition has been built on [Kelly98] where, as long as 347 each user is accountable for the cost their rate causes to others 348 [MKMV95], the set of rates that everyone chooses is deemed fair (cost 349 fairness) - because with any other set of choices people would lose 350 more value than they gained overall. 352 Open Research Issues in Internet Congestion Control Sep. 2010 354 In comparison, the debate between max-min, proportional and TCP 355 fairness is about mere details. These three all share the assumption 356 that equal flow rates are desirable; they merely differ in the second 357 order issue of how to share out excess capacity in a network of many 358 bottlenecks. In contrast, cost fairness should lead to extremely 359 unequal flow rates by design. Equivalently, equal flow rates would 360 typically be considered extremely unfair. 362 The two traditional approaches are not protocol options that can each 363 be followed in different parts of an inter-network. They lead to 364 research agendas that are different in their respective objectives, 365 resulting in a different set of open issues. 367 If we assume TCP-friendliness as a goal with flow rate as the metric, 368 open issues would be: 370 - Should flow fairness depend on the packet rate or the bit rate? 371 - Should the target flow rate depend on RTT (as in TCP) or should 372 only flow dynamics depend on RTT (e.g. as in Fast TCP [Jin04])? 373 - How should we estimate whether a particular flow start strategy is 374 fair, or whether a particular fast recovery strategy after a 375 reduction in rate due to congestion is fair? 376 - Should we judge what is reasonably fair if an application needs, 377 for example, even smoother flows than TFRC, or it needs to 378 burst occasionally, or with any other application behavior? 379 - During brief congestion bursts (e.g. due to new flow arrivals) how 380 should we judge at what point it becomes unfair for some flows to 381 continue at a smooth rate while others reduce their rate? 382 - Which mechanism(s) could be used to enforce approximate flow rate 383 fairness? 384 - Should we introduce some degree of fairness that takes account of 385 different users' flow activity over time? 386 - How should we judge the fairness of applications using a large 387 number of flows over separate paths (e.g. via an overlay)? 389 If we assume cost fairness as a goal with congestion volume as the 390 metric, open issues would be: 392 - Can one application's sensitivity to instantaneous congestion 393 really be protected by longer-term accountability of competing 394 applications? 395 - Which protocol mechanism(s) are needed to give accountability for 396 causing congestion? 397 - How might we design one or two weighted transport protocols (such 398 as TCP, UDP, etc.) with the addition of application policy control 399 over the weight? 400 - Which policy enforcement might be used by networks and what are 401 the interactions between application policy and network policy 402 enforcement? 404 Open Research Issues in Internet Congestion Control Sep. 2010 406 - How to design a new policy enforcement framework that will 407 appropriately compete with existing flows aiming for rate equality 408 (e.g. TCP)? 410 The question of how to reason about fairness is a pre-requisite to 411 agreeing on the research agenda. If the relevant metric is flow-rate 412 it places constraints at protocol design-time, whereas if the metric 413 is congestion volume the constraints move to run-time, while design- 414 time constraints can be relaxed [Bri08]. However, that question does 415 not require more research in itself, it is merely a debate that needs 416 to be resolved by studying existing research and by assessing how bad 417 fairness problems could become if they are not addressed rigorously, 418 and whether we can rely on trust to maintain approximate fairness 419 without requiring policing complexity [RFC5290]. The latter points 420 may themselves lead to additional research. However, it is also 421 accepted that more research will not necessarily lead to convince 422 either side to change their opinions. More debate would be needed. It 423 seems also that if the architecture is built to support cost-fairness 424 then equal instantaneous cost rates for flows sharing a bottleneck 425 result in flow-rate fairness; that is, flow-rate fairness can be seen 426 as a special case of cost-fairness. One can be used to build the 427 other, but not vice-versa. 429 3. Detailed Challenges 431 3.1 Challenge 1: Network Support 433 This challenge is perhaps the most critical to get right. Changes to 434 the balance of functions between the endpoints and network equipment 435 could require a change to the per-datagram data plane interface 436 between the transport and network layers. Network equipment vendors 437 need to be assured that any new interface is stable enough (on decade 438 timescales) to build into firmware and hardware, and OS vendors will 439 not use a new interface unless it is likely to be widely deployed. 441 Network components can be involved in congestion control in two ways: 442 first, they can implicitly optimize their functions, such as queue 443 management and scheduling strategies, in order to support the 444 operation of an end-to-end congestion control. Second, network 445 components can participate in congestion control via explicit 446 signaling mechanisms. Explicit signaling mechanisms, whether in- 447 band or out-of-band, require a communication between network 448 components and end-systems. Signals realized within or over the IP 449 layer are only meaningful to network components that process IP 450 packets. This always includes routers and potentially also 451 middleboxes, but not pure link layer devices. The following section 452 distinguishes clearly between the term "network component" and the 453 term "router"; the term "router" is used whenever the processing of 454 IP packets is explicitly required. One fundamental challenge of 456 Open Research Issues in Internet Congestion Control Sep. 2010 458 network supported congestion control is that typically not all 459 network components along a path are routers (cf. Section 3.1.3). 461 The first (optimizing) category of implicit mechanisms can be 462 implemented in any network component that processes and stores 463 packets. Various approaches have been proposed and also deployed, 464 such as different AQM techniques. Even though these implicit 465 techniques are known to improve network performance during congestion 466 phases, they are still only partly deployed in the Internet. This may 467 be due to the fact that finding optimal and robust parameterizations 468 for these mechanisms is a non-trivial problem. Indeed, the problem 469 with various AQM schemes is the difficulty to identify correct values 470 of the parameter set that affects the performance of the queuing 471 scheme (due to variation in the number of sources, the capacity and 472 the feedback delay) [Firoiu00] [Hollot01] [Zhang03]. Many AQM schemes 473 (RED, REM, BLUE, PI-Controller but also Adaptive Virtual Queue (AVQ)) 474 do not define a systematic rule for setting their parameters. 476 The second class of approaches uses explicit signalling. By using 477 explicit feedback from the network, connection endpoints can obtain 478 more accurate information about the current network characteristics 479 on the path. This allows endpoints to make more precise decisions 480 that can better control congestion. 482 Explicit feedback techniques fall into three broad categories: 483 - Explicit congestion feedback: one bit Explicit Congestion 484 Notification (ECN) [RFC3168] or proposals for more than one bit 485 [Xia05]; 486 - Explicit per-datagram rate feedback: the eXplicit Control Protocol 487 (XCP) [Katabi02] [Falk07], the Rate Control Protocol (RCP) 488 [Dukki05]; 489 - Explicit rate feedback: by means of in-band signaling, such as by 490 Quick-Start [RFC4782] or by means of out-of-band signaling, e.g. 491 CADPC/PTP [Welzl03]. 493 Explicit router feedback can address some of the inherent 494 shortcomings of TCP. For instance, XCP was developed to overcome the 495 inefficiency, and instability that TCP suffers from when the per-flow 496 bandwidth-delay product increases. By decoupling resource 497 utilization/congestion control from fairness control, XCP achieves 498 equal bandwidth allocation, high utilization, a small standing queue 499 size, and near-zero packet drops, with both steady and highly varying 500 traffic. Importantly, XCP does not maintain any per-flow state in 501 routers and requires few CPU cycles per packet, hence making it 502 potentially applicable in high-speed routers. However, XCP is still 503 subject to research: as [Andrew05] has pointed out, XCP is locally 504 stable but globally unstable when the maximum RTT of a flow is much 505 larger than the mean RTT. This instability can be removed by changing 506 the update strategy for the estimation interval, but this makes the 508 Open Research Issues in Internet Congestion Control Sep. 2010 510 system vulnerable to erroneous RTT advertisements. The authors of 511 [PAP02] have shown that, when flows with different RTTs are applied, 512 XCP sometimes discriminates among heterogeneous traffic flows, even 513 if XCP generally equalizes rate among different flows. [Low05] 514 provides for a complete characterization of the XCP equilibrium 515 properties. 517 Several other explicit router feedback schemes have been developed 518 with different design objectives. For instance, RCP uses per-packet 519 feedback similar to XCP. But unlike XCP, RCP focuses on the reduction 520 of flow completion times [Dukki06], taking an optimistic approach to 521 flows likely to arrive in the next RTT and tolerating larger 522 instantaneous queue sizes [Dukki05]. XCP on the other hand gives very 523 poor flow completion times for short flows. 525 Both implicit and explicit router support should be considered in the 526 context of the end-to-end argument [Saltzer84], which is one of the 527 key design principles of the Internet. It suggests that functions 528 that can be realized both in the end-systems and in the network 529 should be implemented in the end-systems. This principle ensures that 530 the network provides a general service and that it remains as simple 531 as possible (any additional complexity is placed above the IP layer, 532 i.e., at the edges) so as to ensure evolvability, reliability and 533 robustness. Furthermore, the fate-sharing principle ([Clark88] 534 "Design Philosophy of the DARPA Internet Protocols") mandates that an 535 end-to-end Internet protocol design should not rely on the 536 maintenance of any per-flow state (i.e., information about the state 537 of the end-to-end communication) inside the network and that the 538 network state (e.g. routing state) maintained by the Internet shall 539 minimize its interaction with the states maintained at the end- 540 points/hosts [RFC1958]. 542 However, as discussed for instance in [Moors02], congestion control 543 cannot be realized as a pure end-to-end function only. Congestion is 544 an inherent network phenomenon and can only be resolved efficiently 545 by some cooperation of end-systems and the network. Congestion 546 control in today's Internet protocols follows the end-to-end design 547 principle insofar as only minimal feedback from the network is used, 548 e.g., packet loss and delay. The end-systems only decide how to 549 react and how to avoid congestion. The crux is that, on the one hand, 550 there would be substantial benefit by further assistance from the 551 network, but, on the other hand, such network support could lead to 552 duplication of functions, which might even harmfully interact with 553 end-to-end protocol mechanisms. The different requirements of 554 applications (cf. the fairness discussion in Section 2.3) call for a 555 variety of different congestion control approaches, but putting such 556 per-flow behavior inside the network should be avoided, as such 557 design would clearly be at odds with the end-to-end and fate sharing 558 design principles. 560 Open Research Issues in Internet Congestion Control Sep. 2010 562 The end-to-end and fate sharing principles are generally regarded as 563 the key ingredients for ensuring a scalable and survivable network 564 design. In order to ensure that new congestion control mechanisms are 565 scalable, violating these principles must therefore be avoided. 567 For instance, protocols like XCP and RCP seem not to require flow 568 state in the network, but this is only the case if the network trusts 569 i) the receiver not to lie when feeding back the network's delta to 570 the requested rate; ii) the source not to lie when declaring its 571 rate; and iii) the source not to cheat when setting its rate in 572 response to the feedback [Katabi04]. 574 Solving these problems for non-cooperative environments like the 575 public Internet requires flow state, at least on a sampled basis. 576 However, because flows can create new identifiers whenever they want, 577 sampling does not provide a deterrent---a flow can simply cheat until 578 it is discovered then switch to a whitewashed identifier [Feldmann04] 579 and continue cheating until it is discovered again [Bri09, S7.3]. 581 However, holding flow state in the network only seems to solve these 582 policing problems in single autonomous system settings. A multi- 583 domain system would seem to require a completely different protocol 584 structure, as the information required for policing is only seen as 585 packets leave the internetwork, but the networks where packets enter 586 will also want to police compliance. 588 Even if a new protocol structure were found, it seems unlikely 589 network flow state could be avoided given the network's per-packet 590 flow rate instructions would need to be compared against variations 591 in the actual flow rate, which is inherently not a per-packet metric. 592 These issues have been outstanding ever since Intserv was identified 593 as unscalable in 1997 [RFC2208]. All subsequent attempts to involve 594 network elements in limiting flow-rates (XCP, RCP etc) will run up 595 against the same open issue if anyone attempts to standardise them 596 for use on the public Internet. 598 In general, network support of congestion control raises many issues 599 that have not been completely solved yet. 601 3.1.1 Performance and Robustness 603 Congestion control is subject to some tradeoffs: on the one hand, it 604 must allow high link utilizations and fair resource sharing but on 605 the other hand, the algorithms must also be robust in particular 606 during congestion phases. 608 Router support can help to improve performance but it can also result 609 in additional complexity and more control loops. This requires a 610 careful design of the algorithms in order to ensure stability and 612 Open Research Issues in Internet Congestion Control Sep. 2010 614 avoid e.g. oscillations. A further challenge is the fact that 615 information may be imprecise. For instance, severe congestion can 616 delay feedback signals. Also, in-network measurement of parameters 617 such as RTTs or data rates may contain estimation errors. Even though 618 there has been significant progress in providing fundamental 619 theoretical models for such effects, research has not completely 620 explored the whole problem space yet. 622 Open questions are: 624 - How much can network elements theoretically improve performance in 625 the complete range of communication scenarios that exists in the 626 Internet without damaging or impacting end-to-end mechanisms 627 already in place? 629 - Is it possible to design robust congestion control mechanisms that 630 offer significant benefits with minimum additional risks, even if 631 the Internet traffic patterns will change in future? 633 - What is the minimum support that is needed from the network in 634 order to achieve significantly better performance than with 635 end-to-end mechanisms and the current IP header limitations that 636 provide at most unary ECN signals? 638 3.1.2 Granularity of network component functions 640 There are several degrees of freedom concerning the involvement of 641 network entities, ranging from some few additional functions in 642 network management procedures on the one end to additional per 643 packet processing on the other end of the solution space. 644 Furthermore, different amounts of state can be kept in routers (no 645 per-flow state, partial per-flow state, soft state, hard state). The 646 additional router processing is a challenge for Internet scalability 647 and could also increase end-to-end latencies. 649 Although there are many research proposals that do not require per- 650 flow state and thus do not cause a large processing overhead, there 651 are no known full solutions (i.e. including anti-cheating) that do 652 not require per-flow processing. Also, scalability issues could also 653 be caused, for instance, by synchronization mechanisms for state 654 information among parallel processing entities, which are e.g. used 655 in high-speed router hardware designs. 657 Open questions are: 659 - What granularity of router processing can be realized without 660 affecting Internet scalability? 662 - How can additional processing efforts be kept at a minimum? 664 Open Research Issues in Internet Congestion Control Sep. 2010 666 3.1.3 Information Acquisition 668 In order to support congestion control, network components have to 669 obtain at least a subset of the following information. Obtaining that 670 information may result in complex tasks. 672 1. Capacity of (outgoing) links 674 Link characteristics depend on the realization of lower protocol 675 layers. Routers operating at IP layer do not necessarily know the 676 link layer network topology and link capacities, and these are not 677 always constant (e.g., on shared wireless links or bandwidth-on- 678 demand links). Depending on the network technology, there can be 679 queues or bottlenecks that are not directly visible at the IP 680 networking layer. 682 Difficulties also arise when using IP-in-IP tunnels [RFC2003] 683 IPsec tunnels [RFC4301], IP encapsulated in L2TP [RFC2661], GRE 684 [RFC1701] [RFC2784], PPTP [RFC2637] or MPLS [RFC3031] [RFC3032]. 685 In these cases, link information could be determined by cross- 686 layer information exchange, but this requires interfaces capable 687 of processing link layer technology specific information. An 688 alternative could be online measurements, but this can cause 689 significant additional network overhead. It is an open research 690 question as how much, if any, online traffic measurement would 691 be acceptable (at run-time). General guidelines for encapsulation 692 and decapsulation of explicit congestion information are currently 693 in preparation [ECN-tunnel]. 695 2. Traffic carried over (outgoing) links 697 Accurate online measurement of data rates is challenging when 698 traffic is bursty. For instance, measuring a "current link load" 699 requires defining the right measurement interval / sampling 700 interval. This is a challenge for proposals that require knowledge 701 e.g. about the current link utilization. 703 3. Internal buffer statistics 705 Some proposals use buffer statistics such as a virtual queue 706 length to trigger feedback. However, network components can 707 include multiple distributed buffer stages that make it difficult 708 to obtain such metrics. 710 Open questions are: 712 - Can and should this information be made available, e.g., by 713 additional interfaces or protocols? 715 Open Research Issues in Internet Congestion Control Sep. 2010 717 - Which information is so important to higher layer controllers that 718 machine architecture research should focus on designing to provide 719 it? 721 3.1.4 Feedback signaling 723 Explicit notification mechanisms can be realized either by in-band 724 signaling (notifications piggybacked along with the data traffic) or 725 by out-of-band signaling [Sarola07]. The latter case requires 726 additional protocols and a secure binding between the signals and the 727 packets they refer to. Out-of-band signaling can be further 728 subdivided into path-coupled and path-decoupled approaches. 730 Open questions concerning feedback signaling include: 732 - At which protocol layer should the feedback signaling occur 733 (IP/network layer assisted, transport layer assisted, hybrid 734 solutions, shim layer, intermediate sub-layer, etc.)? Should the 735 feedback signaling be path-coupled or path-decoupled? 737 - What is the optimal frequency of feedback (only in case of 738 congestion events, per RTT, per packet, etc.)? 740 - What direction should feedback take (from network resource via 741 receiver to sender, or directly back to sender)? 743 3.2 Challenge 2: Corruption Loss 745 It is common for congestion control mechanisms to interpret packet 746 loss as a sign of congestion. This is appropriate when packets are 747 dropped in routers because of a queue that overflows, but there are 748 other possible reasons for packet drops. In particular, in wireless 749 networks, packets can be dropped because of corruption loss, 750 rendering the typical reaction of a congestion control mechanism 751 inappropriate. As a result, non-congestive loss may be more 752 prevalent in these networks due to corruption loss (when the wireless 753 link cannot be conditioned to properly control its error rate or due 754 to transient wireless links interruption in areas of poor coverage). 756 TCP over wireless and satellite is a topic that has been investigated 757 for a long time [Krishnan04]. There are some proposals where the 758 congestion control mechanism would react as if a packet had not been 759 dropped in the presence of corruption (cf. TCP HACK [Balan01]), but 760 discussions in the IETF have shown (see for instance, the discussion 761 that occurred in April 2003 on the DCCP WG list http://www.ietf.org 762 /mail-archive/web/dccp/current/mail6.html) that there is no agreement 763 that this type of reaction is appropriate. For instance, it has been 764 said that congestion can manifest itself as corruption on shared 765 wireless links, and it is questionable whether a source that sends 766 packets that are continuously impaired by link noise should keep 767 sending at a high rate because it has lost the integrity of the 768 feedback loop. 770 Open Research Issues in Internet Congestion Control Sep. 2010 772 Generally, two questions must be addressed when designing congestion 773 control mechanism that takes corruption loss into account: 775 1. How is corruption detected? 777 2. What should be the reaction? 779 In addition to question 1 above, it may be useful to consider 780 detecting the reason for corruption, but this has not yet been done 781 to the best of our knowledge. 783 Corruption detection can be done using an in-band or out-of-band 784 signaling mechanism, much in the same way as described for 785 Challenge 1. Additionally, implicit detection can be considered: link 786 layers sometimes retransmit erroneous frames, which can cause the 787 end-to-end delay to increase - but, from the perspective of a sender 788 at the transport layer, there are many other possible reasons for 789 such an effect. 791 Header checksums provide another implicit detection possibility: if a 792 checksum only covers all the necessary header fields and this 793 checksum does not show an error, it is possible for errors to be 794 found in the payload using a second checksum. Such error detection is 795 possible with UDP-Lite and DCCP; it was found to work well over a 796 GPRS network in a study [Chester04] and poorly over a WiFi network in 797 another study [Rossi06] [Welzl08]. Note that, while UDP-Lite and DCCP 798 enable the detection of corruption, the specifications of these 799 protocols do not foresee any specific reaction to it for the time 800 being. 802 The idea of having a transport end-point detecting and accordingly 803 reacting (or not) to corruption poses a number of interesting 804 questions regarding cross-layer interactions. As IP is designed to 805 operate over arbitrary link layers, it is therefore difficult to 806 design a congestion control mechanism on top of it that appropriately 807 reacts to corruption - especially as the specific data link layers 808 that are in use along an end-to-end path are typically unknown to 809 entities at the transport layer. 811 While the IETF has not yet specified how a congestion control 812 mechanism should react to corruption, proposals exist in the 813 literature, e.g., [Tickoo05]. For instance, TCP Westwood sets the 814 congestion window equal to the measured bandwidth at the time of 815 congestion in response to three DupACKs or a timeout. This 816 measurement is obtained by counting and filtering the ACK rate. This 817 setting provides a significant goodput improvement in noisy channels 818 because the "blind" by half window reduction of standard TCP is 819 avoided, i.e. the window is not reduced by too much [Mascolo01]. 821 Open Research Issues in Internet Congestion Control Sep. 2010 823 Open questions concerning corruption loss include: 825 - How should corruption loss be detected? 827 - How should a source react when it is known that corruption has 828 occurred? 830 - Can an ECN-capable flow infer that loss must be due to corruption 831 just from lack of explicit congestion notifications around a loss 832 episode [LT-TCP]? Or could this inference be dangerous given the 833 transport does not know whether all queues on the path are ECN- 834 capable or not? 836 3.3 Challenge 3: Packet Size 838 TCP does not take packet size into account when responding to losses 839 or ECN. Over past years, the performance of TCP congestion avoidance 840 algorithms has been extensively studied. The well known "square root 841 formula" provides the performance of the TCP congestion avoidance 842 algorithm for TCP Reno [RFC2581]. [Padhye98] enhances the model to 843 account for timeouts, receiver window, and delayed ACKs. 845 For the sake of the present discussion, we will assume that the TCP 846 throughput is expressed using the simplified formula. Using this 847 formula, the TCP throughput B is proportional to the segment size 848 and inversely proportional to the RTT and the square root of the 849 drop probability: 851 S 1 852 B ~ C --- ------- 853 RTT sqrt(p) 855 where, S is the TCP segment size (in bytes) 856 RTT is the end-to-end round trip time of the TCP 857 connection (in seconds) 858 p is the packet drop probability 860 Neglecting the fact that the TCP rate linearly depends on it, 861 choosing the ideal packet size is a trade-off between high throughput 862 (the larger a packet, the smaller the relative header overhead) and 863 low packet latency (the smaller a packet, the shorter the time that 864 is needed until it is filled with data). Observing that TCP is not 865 optimal for applications with streaming media (since reliable in- 866 order delivery and congestion control can cause arbitrarily long 867 delays), this trade-off has not usually been considered for TCP 868 applications. Therefore, the influence of the packet size on the 869 sending rate has not typically been seen as a significant issue, 870 given there are still few paths through the Internet that support 871 packets larger than the 1500Bytes common with Ethernet. 873 Open Research Issues in Internet Congestion Control Sep. 2010 875 The situation is already different for the Datagram Congestion 876 Control Protocol (DCCP) [RFC4340], which has been designed to enable 877 unreliable but congestion-controlled datagram transmission, avoiding 878 the arbitrary delays associated with TCP. DCCP is intended for 879 applications such as streaming media that can benefit from control 880 over the tradeoffs between delay and reliable in-order delivery. 882 DCCP provides for a choice of modular congestion control mechanisms. 883 DCCP uses Congestion Control Identifiers (CCIDs) to specify the 884 congestion control mechanism. Three profiles are currently specified: 886 - DCCP Congestion Control ID 2 (CCID 2) [RFC4341]: TCP-like 887 Congestion Control. CCID 2 sends data using a close approximation 888 of TCP's congestion control, incorporating a variant of SACK 889 [RFC2018], [RFC3517]. CCID 2 is suitable for senders which can 890 adapt to the abrupt changes in congestion window typical of TCP's 891 AIMD congestion control, and particularly useful for senders which 892 would like to take advantage of the available bandwidth in an 893 environment with rapidly changing conditions. 895 - DCCP Congestion Control ID 3 (CCID 3) [RFC4342]: TCP-Friendly Rate 896 Control (TFRC) [RFC5348] is a congestion control mechanism 897 designed for unicast flows operating in a best-effort Internet 898 environment. When competing for bandwidth its window is similar to 899 TCP flows, but has a much lower variation of throughput over time 900 than TCP, making it more suitable for applications such as 901 streaming media where a relatively smooth sending rate is of 902 importance. CCID 3 is appropriate for flows that would prefer to 903 minimize abrupt changes in the sending rate, including streaming 904 media applications with small or moderate receiver buffering 905 before playback. 907 - DCCP Congestion Control ID 4 [RFC5622]: TFRC Small Packets (TFRC- 908 SP) [RFC4828], a variant of the TFRC mechanism has been designed 909 for applications that exchange small packets. The objective of 910 TFRC-SP is to achieve the same bandwidth in bits per second as a 911 TCP flow using packets of up to 1500 bytes. TFRC-SP enforces a 912 minimum interval of 10 ms between data packets to prevent a single 913 flow from sending small packets arbitrarily frequently. CCID 4 has 914 been designed to be used either by applications that use a small 915 fixed segment size, or by applications that change their sending 916 rate by varying the segment size. Because CCID 4 is intended for 917 applications that use a fixed small segment size, or that vary 918 their segment size in response to congestion, the transmit rate 919 derived from the TCP throughput equation is reduced by a factor 920 that accounts for the packet header size, as specified in 921 [RFC4828]. 923 The resulting open questions are: 925 Open Research Issues in Internet Congestion Control Sep. 2010 927 - How does TFRC-SP operate under various network conditions? 929 - How to design congestion control so as to scale with packet 930 size (dependency of congestion algorithm on packet size)? 932 Today, many network resources are designed so that packet processing 933 cannot be overloaded even for incoming loads at the maximum bit-rate 934 of the line. If packet processing can handle sustained load r [packet 935 per second] and the minimum packet size is h [bit] (i.e. frame, 936 packet and transport headers with no payload), then a line rate of x 937 [bit per second] will never be able to overload packet processing as 938 long as x =< r.h. 940 However, realistic equipment is often designed to only cope with a 941 near-worst-case workload with a few larger packets in the mix, rather 942 than the worst-cast of all minimum size packets. In this case, x = 943 r.(h + e) for some small value of e. Therefore, packet-congestion is 944 not impossible for runs of small packets (e.g. TCP ACKs or DoS 945 attacks with TCP SYNs or small UDP datagrams). But absent such 946 anomalous workloads, equipment vendors in at the 2008 ICCRG meeting 947 believed that equipment could still be designed so that any 948 congestion should be due to bit-overload not packet-overload. 950 This observation raises additional open issues: 952 - Can bit congestion remain prevalent? 954 Being able to assume that congestion is generally due to excess 955 bits, not excess packets is a useful simplifying assumption in the 956 design of congestion control protocols. Can we rely on this 957 assumption for the future? An alternative view is that in-network 958 processing will become commonplace, so that per-packet processing 959 will be as likely to be the bottleneck as per-bit transmission 960 [Shin08]. 962 Over the last three decades, performance gains have mainly been 963 achieved through increased packet rates, not bigger packets. But if 964 bigger maximum segment sizes do become more prevalent, tiny 965 segments (e.g. ACKs) will not stop being widely used - leading to a 966 widening range of packet sizes. 968 The open question is thus whether or not packet processing rates 969 (r) will keep up with growth in transmission rates (x). A 970 superficial look at Moore's Law type trends would suggest that 971 processing (r) will continue to outstrip growth in transmission 972 (x). But predictions based on actual knowledge of technology 973 futures would be useful. Another open question is whether there are 974 likely to be more small packets in the average packet mix. If the 975 answers to either of these questions predict that packet congestion 976 could become prevalent, congestion control protocols will have to 977 be more complicated. 979 Open Research Issues in Internet Congestion Control Sep. 2010 981 - Confusable Causes of Loss 983 There is a considerable body of research on how to distinguish 984 whether packet drops are due to transmission corruption or to 985 congestion. But the full list of confusable causes of loss is 986 longer and includes transmission corruption loss, congestion loss 987 (bit congestion and packet congestion), and policing loss. 989 If congestion is due to excess bits, the bit rate should be 990 reduced. If congestion is due to excess packets, the packet rate 991 can be reduced without reducing the bit rate - by using larger 992 packets. However, if the transport cannot tell which of these 993 causes led to a specific packet drop, its only safe response is 994 to reduce the bit rate. This is why the Internet would be more 995 complicated if packet congestion were prevalent, as reducing the 996 bit rate normally also reduces the packet rate, while reducing 997 the packet rate does not necessarily reduce the bit rate. 999 Given distinguishing between corruption loss and congestion is 1000 already an open issue (Section 3.2), if that problem is ever 1001 solved, a further open issue would be whether to standardize a 1002 solution that distinguishes all the above causes of loss, not just 1003 two of them. 1005 Nonetheless, even if we find a way for network equipment to 1006 explicitly distinguish which sort of loss has occurred, we will 1007 never be able to assume that such a smart AQM solution is deployed 1008 at every congestible resource throughout the Internet - at every 1009 higher layer device like firewalls, proxies, servers and at every 1010 lower layer device like low-end Hubs, DSLAMs, WLAN cards, cellular 1011 base-stations and so on. Thus, transport protocols will always 1012 have to cope with packet drops due to unpredictable causes, so we 1013 should always treat, e.g., AQM as an optimization because as long 1014 as it is not ubiquitous throughout the public Internet. 1016 - What does a congestion notification on a packet of a certain size 1017 mean? 1019 The open issue here is whether a loss or explicit congestion mark 1020 should be interpreted as a single congestion event irrespective of 1021 the size of the packet lost or marked, or whether the strength of 1022 the congestion notification is weighted by the size of the packet. 1023 This issue is discussed at length in [Bri08], along with other 1024 aspects of packet size and congestion control. 1026 [Bri08] makes the strong recommendation that network equipment 1027 should drop or mark packets with a probability independent of each 1028 specific packet's size, while congestion controls should respond to 1029 dropped or marked packets in proportion to the packet's size. 1031 Open Research Issues in Internet Congestion Control Sep. 2010 1033 - Packet Size and Congestion Control Protocol Design 1035 If the above recommendation is correct - that the packet size of a 1036 congestion notification should be taken into account when the 1037 transport reads, not when the network writes the notification - it 1038 opens up a significant program of protocol engineering and re- 1039 engineering. Indeed, TCP does not take packet size into account 1040 when responding to losses or ECN. At present this is not a pressing 1041 problem because use of 1500B data segments is very prevalent for 1042 TCP and the incidence of alternative maximum segment sizes is not 1043 large. However, we should design the Internet's protocols so they 1044 will scale with packet size. So, an open issue is whether we should 1045 evolve TCP to be sensitive to packet size, or expect new protocols 1046 to take over. 1048 As we continue to standardize new congestion control protocols, we 1049 must then face the issue of how they should take account of packet 1050 size. It is still an open research issue to establish whether TCP 1051 was correct in not taking packet size into account. If it is 1052 determined that TCP was wrong in this respect, we should discourage 1053 future protocol designs from following TCP's example. For example, 1054 as explained here above, the small-packet variant of TCP-friendly 1055 rate control (TFRC-SP [RFC4828]) is an experimental protocol that 1056 aims to take account of packet size. Whatever packet size it uses, 1057 it ensures its rate approximately equals that of a TCP using 1500B 1058 segments. This raises the further question of whether TCP with 1059 1500B segments will be a suitable long-term gold standard, or 1060 whether we need a more thorough review of what it means for a 1061 congestion control to scale with packet size. 1063 3.4 Challenge 4: Flow Startup 1065 The beginning of data transmissions imposes some further, unique 1066 challenges: when a connection to a new destination is established, 1067 the end-systems have hardly any information about the characteristics 1068 of the path in between and the available bandwidth. In this flow 1069 startup situation there is no obvious choice how to start to send. A 1070 similar problem also occurs after relatively long idle times, since 1071 the congestion control state then no longer reflects current 1072 information about the state of the network (flow restart problem). 1074 Van Jacobson [Jacobson88] suggested using the slow-start mechanism 1075 both for the flow startup and the flow restart, and this is today's 1076 standard solution [RFC2581] [RFC5681]. Per [RFC5681], the slow-start 1077 algorithm is used when the congestion window (cwnd) < slow start 1078 threshold (ssthresh), whose initial value is set arbitrarily high 1079 (e.g., to the size of the largest possible advertised window) and 1080 reduced in response to congestion. During slow start, TCP increments 1081 the cwnd by at most Sender MSS bytes for each ACK received that 1083 Open Research Issues in Internet Congestion Control Sep. 2010 1085 cumulatively acknowledges new data. Slow start ends when cwnd 1086 exceeds ssthresh or when congestion is observed. However, the slow- 1087 start is not optimal in many situations. First, it can take quite a 1088 long time until a sender can fully utilize the available bandwidth 1089 on a path. Second, the exponential increase may be too aggressive 1090 and cause multiple packet loss if large congestion windows are 1091 reached (slow-start overshooting). Finally, the slow-start does not 1092 ensure that new flows converge quickly to a reasonable share of 1093 resources, in particular, when the new flows compete with long- 1094 lived flows and comes out of slow-start early (slow-start vs 1095 overshoot trade-off). This convergence problem may even worsen if 1096 more aggressive congestion control variants get widely used. 1098 The slow-start and its interaction with the congestion avoidance 1099 phase was largely designed by intuition [Jacobson88]. So far, little 1100 theory has been developed to understand the flow startup problem and 1101 its implication on congestion control stability and fairness. There 1102 is also no established methodology to evaluate whether new flow 1103 startup mechanisms are appropriate or not. 1105 As a consequence, it is a non-trivial task to address the 1106 shortcomings of the slow-start algorithm. Several experimental 1107 enhancements have been proposed, such as congestion window validation 1108 [RFC2861] and limited slow-start [RFC3742]. There are also ongoing 1109 research activities, focusing e.g. on bandwidth estimation 1110 techniques, delay-based congestion control, or rate pacing 1111 mechanisms. However, any alternative end-to-end flow startup approach 1112 has to cope with the inherent problem that there is no or only little 1113 information about the path at the beginning of a data transfer. This 1114 uncertainty could be reduced by more expressive feedback signaling 1115 (cf. Section 3.1). For instance, a source could learn the path 1116 characteristics faster with the Quick-Start mechanism [RFC4782]. But, 1117 even if the source knew exactly what rate it should aim for, it would 1118 still not necessarily be safe to jump straight to that rate. The end- 1119 system still does not know how a change in its own rate will affect 1120 the path, which also might become congested in less than one RTT. 1121 Further research would be useful to understand the effect of 1122 decreasing the uncertainty by explicit feedback separately from 1123 control theoretic stability questions. Furthermore, flow startup 1124 also raises fairness questions. For instance, it is unclear whether 1125 it could be reasonable to use a faster startup when an end-system 1126 detects that a path is currently not congested. 1128 In summary, there are several topics for further research concerning 1129 flow startup: 1131 - Better theoretical understanding of the design and evaluation of 1132 flow startup mechanisms, concerning their impact on congestion 1133 risk, stability, and fairness. 1135 Open Research Issues in Internet Congestion Control Sep. 2010 1137 - Evaluate whether it may be appropriate to allow alternative 1138 starting schemes, e.g., to allow higher initial rates under certain 1139 constraints; this also requires refining the definition of fairness 1140 for startup situations. 1142 - Better theoretical models for the effects of decreasing 1143 uncertainty by additional network feedback, in particular if the 1144 path characteristics are very dynamic. 1146 3.5 Challenge 5: Multi-domain Congestion Control 1148 Transport protocols such as TCP operate over the Internet, which is 1149 divided into autonomous systems. These systems are characterized by 1150 their heterogeneity as IP networks are realized by a multitude of 1151 technologies. 1153 3.5.1 Multi-domain Transport of Explicit Congestion Notification 1155 The variety of conditions and their variations leads to correlation 1156 effects between policers that regulate traffic against certain 1157 conformance criteria. 1159 With the advent of techniques allowing for early detection of 1160 congestion, packet loss is no longer the sole metric of congestion. 1161 ECN (Explicit Congestion Notification) marks packets - set by active 1162 queue management techniques - to convey congestion information trying 1163 to prevent packet losses (packet loss and the number of packets 1164 marked gives an indication of the level of congestion). Using TCP 1165 ACKs to feed back that information allows the hosts to realign their 1166 transmission rate and thus, encourages them to efficiently use the 1167 network. In IP, ECN uses the two unused bits of the Type Of Service 1168 (TOS) field [RFC2474]. Further, ECN in TCP uses two bits in the TCP 1169 header that were previously defined as reserved [RFC793]. 1171 ECN [RFC3168] is an example of a congestion feedback mechanism from 1172 the network toward hosts. The congestion-based feedback scheme 1173 however has limitations when applied on an inter-domain basis. 1174 Indeed, Sections 8 and 19 of [RFC3168] details the implications 1175 of two possible attacks: 1177 i) non-compliance: a network erasing CE introduced earlier on the 1178 path, and 1180 ii) subversion: a network changing Not-ECN Capable Transport (Not- 1181 ECT) to ECT. 1183 Both of which could allow an attacking network to cause excess 1184 congestion in an upstream network, even if the transports were 1185 behaving correctly. There are to date two possible solutions to the 1187 Open Research Issues in Internet Congestion Control Sep. 2010 1189 non-compliance problem (number i above): the ECN-nonce [RFC3540] and 1190 the re-ECN incentive system [Bri09]. Nevertheless, accidental rather 1191 than malicious erasure of ECN is an issue for IPv6 where the absence 1192 of an IPv6 header checksum implies that corruption of ECN could be 1193 more impacting than in the IPv4 case. 1195 Fragmentation is another issue: the ECN-nonce cannot protect against 1196 misbehaving receivers that conceal marked fragments; thus, some 1197 protection is lost in situations where Path MTU discovery is 1198 disabled. Note also that ECN-nonce wouldn't protect against the 1199 subversion issue (number ii above) because, by definition, a Not-ECT 1200 packet comes from a source without ECN enabled, and therefore, 1201 without the ECN-nonce enabled. So, there is still room for 1202 improvement on the ECN mechanism when operating in multi-domain 1203 networks. 1205 Operational/deployment experience is nevertheless required to 1206 determine the extent of these problems. The second problem is mainly 1207 related to deployment and usage practices and does not seem to result 1208 in any specific research challenge. 1210 Another controversial solution in a multi-domain environment may be 1211 the TCP rate controller (TRC), a traffic conditioner which regulates 1212 the TCP flow at the ingress node in each domain by controlling packet 1213 drops and delays of the packets in a flow. The outgoing traffic from 1214 a TRC controlled domain is shaped in such a way that no packets are 1215 dropped at the policer. However, the TRC interferes with the end-to- 1216 end TCP model, and thus it would interfere with past and future 1217 diversity of TCP implementations (violating the end-to-end 1218 principle). In particular, the TRC embeds the flow rate equality view 1219 of fairness in the network, and would prevent evolution to forms of 1220 fairness based on congestion-volume (Section 2.3). 1222 3.5.2 Multi-domain Exchange of Topology or Explicit Rate Information 1224 Security is a challenge for multi-domain exchange of explicit rate 1225 signals, whether in-band or out-of-band. At domain boundaries, 1226 authentication and authorization issues can arise whenever congestion 1227 control information is exchanged. From this perspective, the Internet 1228 does not so far have any security architecture for this problem. 1230 The future evolution of the Internet inter-domain operation has to 1231 show whether more multi-domain information exchange can be 1232 effectively realized. This is of particular importance for congestion 1233 control schemes that make use of explicit per-datagram rate feedback 1234 (e.g. RCP or XCP) or explicit rate feedback that use in-band 1235 congestion signaling (e.g. QuickStart) or out-of-band signaling (e.g. 1236 CADPC/PTP). Explicit signaling exchanges at the inter-domain level 1237 that result in local domain triggers are currently absent from the 1238 Internet. From this perspective, security means resulting from 1240 Open Research Issues in Internet Congestion Control Sep. 2010 1242 limited trust between different administrative units result in policy 1243 enforcement that exacerbates the difficulty encountered when explicit 1244 feedback congestion control information is exchanged between domains. 1245 Note that even though authentication mechanisms could be extended for 1246 this purpose (by recognizing that explicit rate schemes such as RCP 1247 or XCP have the same inter-domain security requirements and structure 1248 as IntServ), they suffer from the same scalability problems as 1249 identified in [RFC2208]. Indeed, in-band rate signaling or out-of- 1250 band per-flow traffic specification signaling (like in RSVP) results 1251 in similar scalability issues. 1253 Also, many autonomous systems also only exchange some limited amount 1254 of information about their internal state (topology hiding 1255 principle), even though having more precise information could be 1256 highly beneficial for congestion control. Indeed, revealing the 1257 internal network structure is highly sensitive in multi-domain 1258 network operations and thus, also a concern when it comes to the 1259 deployability of congestion control schemes. For instance, a network- 1260 assisted congestion control scheme with explicit signaling could 1261 reveal more information about the internal network dimensioning than 1262 TCP does today. 1264 3.5.3 Multi-domain Pseudowires 1266 Extending pseudo-wires across multiple domains poses specific issues. 1267 Pseudowires (PW) [RFC3985] may carry non-TCP data flows (e.g. TDM 1268 traffic) over a multi-domain IP network. Structure Agnostic TDM over 1269 Packet (SATOP) [RFC4553], Circuit Emulation over Packet Switched 1270 Networks (CESoPSN), TDM over IP, are not responsive to congestion 1271 control as discussed by [RFC2914] (see also [RFC5033]). 1273 Moreover, it is not possible to simply reduce the flow rate of a TDM 1274 PW when facing packet loss. Providers can rate control corresponding 1275 incoming traffic but they may not be able to detect that PWs carry 1276 TDM traffic (mechanisms for characterizing the traffic temporal 1277 properties may not necessarily be supported). This can be illustrated 1278 with the following example. 1280 ........... ............ 1281 . . . 1282 S1 --- E1 --- . . 1283 . | . . 1284 . === E5 === E7 --- 1285 . | . . | 1286 S2 --- E2 --- . . | 1287 . . . | | 1288 ........... . | v 1289 . ----- R ---> 1290 ........... . | ^ 1292 Open Research Issues in Internet Congestion Control Sep. 2010 1294 . . . | | 1295 S3 --- E3 --- . . | 1296 . | . . | 1297 . === E6 === E8 --- 1298 . | . . 1299 S4 --- E4 --- . . 1300 . . . 1301 ........... ............ 1303 \---- P1 ---/ \---------- P2 ----- 1305 Sources S1, S2, S3 and S4 are originating TDM over IP traffic. P1 1306 provider edges E1, E2, E3, and E4 are rate limiting such traffic. The 1307 SLA of provider P1 with transit provider P2 is such that the latter 1308 assumes a BE traffic pattern and that the distribution shows the 1309 typical properties of common BE traffic (elastic, non-real time, non- 1310 interactive). 1312 The problem arises for transit provider P2 that is not able to detect 1313 that IP packets are carrying constant-bit rate service traffic for 1314 which the only useful congestion control mechanism would rely on 1315 implicit or explicit admission control, meaning self-blocking or 1316 enforced blocking respectively. 1318 Assuming P1 providers are rate limiting BE traffic, a transit P2 1319 provider router R may be subject to serious congestion as all TDM PWs 1320 cross the same router. TCP-friendly traffic (e.g. each flow within 1321 the PW) would follow TCP's AIMD algorithm of reducing the sending 1322 rate in half in response to each packet drop. Nevertheless, the PWs 1323 carrying TDM traffic could take all the available capacity while 1324 other more TCP-friendly or generally congestion-responsive traffic 1325 reduced itself to nothing. Note here that the situation may simply 1326 occur because S4 suddenly turns on additional TDM channels. 1328 It is neither possible nor desirable to assume that edge routers will 1329 soon have the ability to detect the responsiveness of the carried 1330 traffic, but it is still important for transit providers to be able 1331 to police a fair, robust, responsive and efficient congestion control 1332 technique in order to avoid impacting congestion responsive Internet 1333 traffic. However, we must not require only certain specific responses 1334 to congestion to be embedded within the network, which would harm 1335 evolvability. So designing the corresponding mechanisms in the data 1336 and control planes still requires further investigation. 1338 3.6 Challenge 6: Precedence for Elastic Traffic 1340 Traffic initiated by so-called elastic applications adapt to the 1341 available bandwidth using feedback about the state of the network. 1343 Open Research Issues in Internet Congestion Control Sep. 2010 1345 For all these flows the application dynamically adjusts the data 1346 generation rate. Examples encompass short-lived elastic traffic 1347 including HTTP and instant messaging traffic as well as long file 1348 transfers with FTP. In brief, elastic data applications can show 1349 extremely different requirements and traffic characteristics. 1351 The idea to distinguish several classes of best-effort traffic types 1352 is rather old, since it would be beneficial to address the relative 1353 delay sensitivities of different elastic applications. The notion of 1354 traffic precedence was already introduced in [RFC791], and it was 1355 broadly defined as "An independent measure of the importance of this 1356 datagram." For instance, low precedence traffic should experience 1357 lower average throughput than higher precedence traffic. Several 1358 questions arise here: what is the meaning of "relative"? What is the 1359 role of the Transport Layer? 1361 The preferential treatment of higher precedence traffic combined with 1362 appropriate congestion control mechanisms is still an open issue that 1363 may, depending on the proposed solution, impact both the host and the 1364 network precedence awareness, and thereby congestion control. 1365 [RFC2990] points out that the interactions between congestion control 1366 and DiffServ [RFC2475] remained unaddressed up to recently. 1368 Recently, a study and a potential solution have been proposed that 1369 introduce Guaranteed TFRC (gTFRC) [Lochin06]. gTFRC is an adaptation 1370 of TCP-Friendly Rate Control providing throughput guarantee for 1371 unicast flows over the DiffServ/AF class. The purpose of gTFRC is to 1372 distinguish the guaranteed part from the best-effort part of the 1373 traffic resulting from AF conditioning. The proposed congestion 1374 control has been specified and tested inside DCCP/CCID3 for 1375 DiffServ/AF networks [Lochin07]. A complete reliable transport 1376 protocol based-on gTFRC and SACK appears to be the first reliable 1377 DiffServ/AF compliant transport protocol [Jourjon08]. 1379 Nevertheless, there is still work to be performed regarding lower 1380 precedence traffic - data transfers which are useful, yet not 1381 important enough to warrant significantly impairing other traffic. 1382 Examples of applications that could make use of such traffic are web 1383 caches and web browsers (e.g. for pre-fetching) as well as peer-to- 1384 peer applications. There are proposals for achieving low precedence 1385 on a pure end-to-end basis (e.g. TCP-LP [Kuzmanovic03]), and there is 1386 a specification for achieving it via router mechanisms [RFC3662]. It 1387 seems, however, that network-based lower precedence mechanisms are 1388 not yet a common service on the Internet. There is an expectation 1389 that end-to-end mechanisms for lower precedence e.g. [LEDBAT] could 1390 become common --at least when competing with other traffic as part of 1391 its own queues (e.g. in a home router). But it is less clear whether 1392 user will be willing to make their background traffic yield to other 1393 people's foreground traffic unless the appropriate incentives are 1394 created. 1396 Open Research Issues in Internet Congestion Control Sep. 2010 1398 There is an issue over how to reconcile two divergent views of the 1399 relation between traffic class precedence and congestion control. One 1400 view considers that congestion signals (losses or explicit 1401 notifications) in one traffic class are independent of those in 1402 another. The other relates marking of the classes together within the 1403 active queue management (AQM) mechanism [Gibbens02]. In the 1404 independent case, using a higher precedence class of traffic gives a 1405 higher scheduling precedence and generally lower congestion level. In 1406 the linked case, higher precedence still gives higher scheduling 1407 precedence, but results in a higher level of congestion. This higher 1408 congestion level reflects the extra congestion higher precedence 1409 traffic causes to both classes combined. The linked case separates 1410 scheduling precedence from rate control. The end-to-end congestion 1411 control algorithm can separately choose to take a higher rate by 1412 responding less to the higher level of congestion. This second 1413 approach could become prevalent if weighted congestion controls were 1414 common. However, it is an open issue how the two approaches might co- 1415 exist or how one might evolve into the other. 1417 3.7 Challenge 7: Misbehaving Senders and Receivers 1419 In the current Internet architecture, congestion control depends on 1420 parties acting against their own interests. It is not in a receiver's 1421 interest to honestly return feedback about congestion on the path, 1422 effectively requesting a slower transfer. It is not in the sender's 1423 interest to reduce its rate in response to congestion if it can rely 1424 on others to do so. Additionally, networks may have strategic reasons 1425 to make other networks appear congested. 1427 Numerous strategies to improve congestion control have already been 1428 identified. The IETF has particularly focused on misbehaving TCP 1429 receivers that could confuse a compliant sender into assigning 1430 excessive network and/or server resources to that receiver (e.g. 1431 [Savage99], [RFC3540]). But, although such strategies are worryingly 1432 powerful, they do not yet seem common (however, evidence of attack 1433 prevalence is itself a research requirement). 1435 A growing proportion of Internet traffic comes from applications 1436 designed not to use congestion control at all, or worse, applications 1437 that add more forward error correction the more losses they 1438 experience. Some believe the Internet was designed to allow such 1439 freedom so it can hardly be called misbehavior. But others consider 1440 that it is misbehavior to abuse this freedom [RFC3714], given one 1441 person's freedom can constrain the freedom of others (congestion 1442 represents this conflict of interests). Indeed, leaving freedom 1443 unchecked might result in congestion collapse in parts of the 1444 Internet. Proportionately, large volumes of unresponsive voice 1445 traffic could represent such a threat, particularly for countries 1446 with less generous provisioning [RFC3714]. Also, Internet video on 1448 Open Research Issues in Internet Congestion Control Sep. 2010 1450 demand services are becoming popular that transfer much greater data 1451 rates without congestion control. In general, it is recommended that 1452 such UDP applications use some form of congestion control [RFC5405]. 1454 Note that the problem is not just misbehavior driven by a self- 1455 interested desire for more bandwidth. Indeed, congestion control may 1456 be attacked by someone who makes no gain for themselves, other than 1457 the satisfaction of harming others (see Security Considerations in 1458 Section 4). 1460 Open research questions resulting from these considerations are: 1462 - By design, new congestion control protocols need to enable one end 1463 to check the other for protocol compliance. Still, it is unclear 1464 how such mechanisms would have to be designed. 1466 - Which congestion control primitives could safely satisfy more 1467 demanding applications (smoother than TFRC, faster than high speed 1468 TCPs), so that application developers and users do not turn off 1469 congestion control to get the rate they expect and need. 1471 Note also that self-restraint could disappear from the Internet. 1472 So, it may no longer be sufficient to rely on developers/users 1473 voluntarily submitting themselves to congestion control. As a 1474 consequence, mechanisms to enforce fairness (see Sections 2.3, 3.4, 1475 and 3.5) need to have more emphasis within the research agenda. 1477 3.8 Other Challenges 1479 This section provides additional challenges and open research issues 1480 that are not (at this point in time) deemed very large or of 1481 different nature compared to the main challenges depicted so far. 1483 3.8.1 RTT Estimation 1485 Several congestion control schemes have to precisely know the round- 1486 trip time (RTT) of a path. The RTT is a measure of the current delay 1487 on a network. It is defined as the delay between the sending of a 1488 packet and the reception of a corresponding response, if echoed back 1489 immediately by the receiver upon receipt of the packet. This 1490 corresponds to the sum of the one-way delay of the packet and the 1491 (potentially different) one-way delay of the response. Furthermore, 1492 any RTT measurement also includes some additional delay due to the 1493 packet processing in both end-systems. 1495 There are various techniques to measure the RTT: active measurements 1496 inject special probe packets to the network and then measure the 1497 response time, using e.g. ICMP. In contrast, passive measurements 1499 Open Research Issues in Internet Congestion Control Sep. 2010 1501 determine the RTT from ongoing communication processes, without 1502 sending additional packets. 1504 The connection endpoints of transport protocols such as TCP, SCTP, 1505 and DCCP, as well as several application protocols, keep track of the 1506 RTT in order to dynamically adjust protocol parameters such as the 1507 retransmission timeout (RTO) or the rate control equation. They can 1508 implicitly measure the RTT on the sender side by observing the time 1509 difference between the sending of data and the arrival of the 1510 corresponding acknowledgements. For TCP, this is the default RTT 1511 measurement procedure, in combination with Karn's algorithm that 1512 prohibits RTT measurements from retransmitted segments [RFC2988]. 1513 Traditionally, TCP implementations take one RTT measurement at a time 1514 (i.e., about once per RTT). As alternative, the TCP timestamp option 1515 [RFC1323] allows more frequent explicit measurements, since a sender 1516 can safely obtain an RTT sample from every received acknowledgment. 1517 In principle, similar measurement mechanisms are used by protocols 1518 other than TCP. 1520 Sometimes it would be beneficial to know the RTT not only at the 1521 sender, but also at the receiver, e.g., to find the one-way variation 1522 in delay due to one-way congestion. A passive receiver can deduce 1523 some information about the RTT by analyzing the sequence numbers of 1524 received segments. But this method is error-prone and only works if 1525 the sender permanently sends data. Other network entities on the path 1526 can apply similar heuristics in order to approximate the RTT of a 1527 connection, but this mechanism is protocol-specific and requires per- 1528 connection state. In the current Internet, there is no simple and 1529 safe solution to determine the RTT of a connection in network 1530 entities other than the sender. The more fundamental question being 1531 to determine whether it is necessary or not for network elements to 1532 measure or know the RTT. 1534 As outlined earlier in this document, the round-trip time is 1535 typically not a constant value. For a given path, there is 1536 theoretical minimum value, which is given by the minimum 1537 transmission, processing and propagation delay on that path. However, 1538 additional variable delays might be caused by congestion, cross- 1539 traffic, shared mediums access control schemes, recovery procedures, 1540 or other sub-IP layer mechanisms. Furthermore, a change of the path 1541 (e.g., route flapping, hand-over in mobile networks) can result in 1542 completely different delay characteristics. 1544 Due to this variability, one single measured RTT value is hardly 1545 sufficient to characterize a path. This is why many protocols use RTT 1546 estimators that derive an averaged value and keep track of a certain 1547 history of previous samples. For instance, TCP endpoints derive a 1548 smoothed round-trip time (SRTT) from an exponential weighted moving 1549 average [RFC2988]. Such a low-pass filter ensures that measurement 1551 Open Research Issues in Internet Congestion Control Sep. 2010 1553 noise and single outliers do not significantly affect the estimated 1554 RTT. Still, a fundamental drawback of low-pass filters is that the 1555 averaged value reacts slower to sudden changes of the measured RTT. 1556 There are various solutions to overcome this effect: For instance, 1557 the standard TCP retransmission timeout calculation considers not 1558 only the SRTT, but also a measure for the variability of the RTT 1559 measurements [RFC2988]. Since this algorithm is not well-suited for 1560 frequent RTT measurements with timestamps, certain implementations 1561 modify the weight factors (e.g., [SK02]). There are also proposals 1562 for more sophisticated estimators, such as Kalman filters or 1563 estimators that utilize mainly peak values. 1565 However, open questions concerning RTT estimation in the Internet 1566 remain: 1568 - Optimal measurement frequency: Currently, there is no theory of 1569 common understanding of the right time scale of RTT measurement. In 1570 particular, the necessity of rather frequent measurements 1571 (e.g., per packet) is not well understood. There is some empirical 1572 evidence that such frequent sampling may not have a significant 1573 benefit [Allman99]. 1575 - Filter design: A closely related question is how to design good 1576 filters for the measured samples. The existing algorithms are known 1577 to be robust, but they are far from being perfect. The fundamental 1578 problem is that there is no single set of RTT values that could 1579 characterize the Internet as a whole, i.e., it is hard to define a 1580 design target. 1582 - Default values: RTT estimators can fail in certain scenarios, e.g., 1583 when any feedback is missing. In this case, default values have 1584 to be used. Today, most default values are set to conservative 1585 values that may not be optimal for most Internet communication. 1586 Still, the impact of more aggressive settings is not well 1587 understood. 1589 - Clock granularities: RTT estimation depends on the clock 1590 granularities of the protocol stacks. Even though there is a trend 1591 towards higher precision timers, the limited granularity 1592 (particularly on low cost devices) may still prevent highly 1593 accurate RTT estimations. 1595 3.8.2 Malfunctioning Devices 1597 There is a long history of malfunctioning devices harming the 1598 deployment of new and potentially beneficial functionality in the 1599 Internet. Sometimes, such devices drop packets or even crash 1600 completely when a certain mechanism is used, causing users to opt for 1602 Open Research Issues in Internet Congestion Control Sep. 2010 1604 reliability instead of performance and disable the mechanism, or 1605 operating system vendors to disable it by default. One well-known 1606 example is ECN, whose deployment was long hindered by malfunctioning 1607 firewalls and is still hindered by malfunctioning home-hubs, but 1608 there are many other examples (e.g. the Window Scaling option of TCP) 1609 [Thaler07]. 1611 As new congestion control mechanisms are developed with the intention 1612 of eventually seeing them deployed in the Internet, it would be 1613 useful to collect information about failures caused by devices of 1614 this sort, analyze the reasons for these failures, and determine 1615 whether there are ways for such devices to do what they intend to do 1616 without causing unintended failures. Recommendation for vendors of 1617 these devices could be derived from such an analysis. It would also 1618 be useful to see whether there are ways for failures caused by such 1619 devices to become more visible to endpoints, or for those failures to 1620 become more visible to the maintainers of such devices. 1622 A possible way to reduce such problems in the future would be 1623 guidelines for standards authors to ensure `forward compatibility' is 1624 considered in all IETF work. That is, the default behavior of a 1625 device should be precisely defined for all possible values and 1626 combinations of protocol fields, not just the minimum necessary for 1627 the protocol being defined. Then when previously unused or reserved 1628 fields start to be used by newer devices to comply with a new 1629 standard, older devices encountering unusual fields should at least 1630 behave predictably. 1632 3.8.3 Dependence on RTT 1634 AIMD window algorithms that have the goal of packet conservation end 1635 up converging on a rate that is inversely proportional to RTT. 1636 However, control theoretic approaches to stability have shown that 1637 only the increase in rate (acceleration) not the target rate needs to 1638 be inversely proportional to RTT. 1640 It is possible to have more aggressive behaviors for some demanding 1641 applications as long as they are part of a mix with less aggressive 1642 transports [Key04]. This beneficial effect of transport type mixing 1643 is probably how the Internet currently manages to remain stable even 1644 in the presence of TCP slow start, which is more aggressive than the 1645 theory allows for stability. Research giving deeper insight into 1646 these aspects would be very useful. 1648 3.8.4 Congestion Control in Multi-layered Networks 1650 A network of IP nodes is just as vulnerable to congestion in the 1651 lower layers between IP-capable nodes as it is to congestion on the 1653 Open Research Issues in Internet Congestion Control Sep. 2010 1655 IP-capable nodes themselves. If network elements take a greater part 1656 in congestion control (ECN, XCP, RCP, etc. - see Section 3.1), these 1657 techniques will either need to be deployed at lower layers as well, 1658 or they will need to interwork with lower layer mechanisms. 1660 [ECN-tunnel] gives guidelines on propagating ECN from lower layers 1661 upwards, but to the authors' knowledge the layering problem has not 1662 been addressed for explicit rate protocol proposals such as XCP and 1663 RCP. Some issues are straightforward matters of interoperability 1664 (e.g. how exactly to copy fields up the layers) while others are 1665 less obvious (e.g. re-framing issues: if RCP were deployed in a lower 1666 layer, how might multiple small RCP frames all with different rates 1667 in their headers be assembled into a larger IP-layer datagram?). 1669 Multi-layer considerations also confound many mechanisms that aim to 1670 discover whether every node on the path supports the new congestion 1671 control protocol. For instance, some proposals maintain a secondary 1672 TTL field parallel to that in the IP header. Any nodes that support 1673 the new behavior update both TTL fields, whereas legacy IP nodes will 1674 only update the IP TTL field. This allows the endpoints to check 1675 whether all IP nodes on the path support the new behavior, in which 1676 case both TTLs will be equal at the receiver. But mechanisms like 1677 these overlook nodes at lower layers that might not support the new 1678 behavior. 1680 A further related issue is congestion control across overlay networks 1681 of relays [Hilt08, Noel07, Shen08]]. 1683 3.8.5 Multipath End-to-end Congestion Control and Traffic Engineering 1685 Recent work has shown that multipath endpoint congestion control 1686 [Kelly05] offers considerable benefits in terms of resilience and 1687 resource usage efficiency. By pooling the resources on all paths, 1688 even nodes not using multiple paths benefit from those that are. 1690 There is considerable further research to do in this area, 1691 particularly to understand interactions with network operator 1692 controlled route provision and traffic engineering, and indeed 1693 whether multipath congestion control can perform better traffic 1694 engineering than the network itself, given the right incentives. 1696 3.8.6 ALGs and Middleboxes 1698 An increasing number of application layer gateways (ALG), 1699 middleboxes, and proxies (see Section 3.6 of [RFC2775]) is deployed 1700 at domain boundaries to verify conformance but also filter traffic 1701 and control flows. One motivation is to prevent information beyond 1702 routing data leaking between autonomous systems. These systems split 1704 Open Research Issues in Internet Congestion Control Sep. 2010 1706 up end-to-end TCP connections and disrupt end-to-end congestion 1707 control. Furthermore, transport over encrypted tunnels may not allow 1708 other network entities to participate in congestion control. 1710 Basically, such systems disrupt the primal and dual congestion 1711 control components. In particular, end-to-end congestion control may 1712 be replaced by flow-control backpressure mechanisms on the split 1713 connections. A large variety of ALGs and middleboxes use such 1714 mechanisms to improve the performance of applications (Performance 1715 Enhancing Proxies, Application Accelerators, etc.). However, the 1716 implications of such mechanisms, which are often proprietary and not 1717 documented, have not been studied systematically so far. 1719 There are two levels of interference: 1721 - The "transparent" case, i.e. the end-point address from the sender 1722 perspective is still visible to the receiver (the destination IP 1723 address). An example are relay systems that intercept payload but 1724 do not relay congestion control information. Such middleboxes can 1725 prevent the operation of end-to-end congestion control. 1727 - The "non-transparent" case, which causes less problems. Although 1728 these devices interfere with end-to-end network transparency, they 1729 correctly terminate network, transport and application layer 1730 protocols on both sides, which individually can be congestion 1731 controlled. 1733 4. Security Considerations 1735 Misbehavior may be driven by pure malice, or malice may in turn be 1736 driven by wider selfish interests, e.g. using distributed denial of 1737 service (DDoS) attacks to gain rewards by extortion [RFC4948]. DDoS 1738 attacks are possible both because of vulnerabilities in operating 1739 systems and because the Internet delivers packets without requiring 1740 congestion control. 1742 To date, compliance with congestion control rules and being fair 1743 requires end points to cooperate. The possibility of uncooperative 1744 behavior can be regarded as a security issue; its implications are 1745 discussed throughout these documents in a scattered fashion. 1747 Currently the focus of the research agenda against denial of service 1748 is about identifying attack packets, attacking machines and networks 1749 hosting them, with a particular focus on mitigating source address 1750 spoofing. But if mechanisms to enforce congestion control fairness 1751 were robust to both selfishness and malice [Bri06] they would also 1752 naturally mitigate denial of service against the network, which can 1753 be considered (from the perspective of well-behaving Internet user) 1754 as a congestion control enforcement problem. Even some denial of 1756 Open Research Issues in Internet Congestion Control Sep. 2010 1758 service attacks on hosts (rather than the network) could be 1759 considered as a congestion control enforcement issue at the higher 1760 layer. But clearly there are also denial of service attacks that 1761 would not be solved by enforcing congestion control. 1763 Sections 3.5 and 3.7 on multi-domain issues and misbehaving senders 1764 and receivers also discuss some information security issues suffered 1765 by various congestion control approaches. 1767 5. IANA Considerations 1769 This document has no IANA actions. 1771 Open Research Issues in Internet Congestion Control Sep. 2010 1773 6. References 1775 6.1 Informative References 1777 [Allman99] Allman, M., and V. Paxson, "On Estimating End-to-End 1778 Network Path Properties", Proceedings of ACM SIGCOMM'99, 1779 September 1999. 1781 [Andrew05] Andrew, L., Wydrowski, B., and S. Low, "An Example of 1782 Instability in XCP", Manuscript available at 1783 1785 [Ath01] Athuraliya, S., Low, S., Li, V., and Q. Yin, "REM: Active 1786 Queue Management", IEEE Network Magazine, Vol.15, No.3, 1787 pp.48-53, May 2001. 1789 [Balan01] Balan, R. K., Lee, B.P., Kumar, K.R.R., Jacob, L., Seah, 1790 W.K.G., and Ananda, A.L., "TCP HACK: TCP Header Checksum 1791 Option to Improve Performance over Lossy Links", 1792 Proceedings of IEEE INFOCOM'01, Anchorage (Alaska), USA, 1793 April 2001. 1795 [Bonald00] Bonald, T., May, M., and J.-C. Bolot, "Analytic 1796 Evaluation of RED Performance," Proceedings of IEEE 1797 INFOCOM'00, Tel Aviv, Israel, March 2000. 1799 [Bri08] Briscoe, B., Moncaster, T. and L. Burness, "Problem 1800 Statement: Transport Protocols Don't Have To Do 1801 Fairness", Work in progress, draft-briscoe-tsvwg-relax- 1802 fairness-01, July 2008. 1804 [Bri06] Briscoe, B., "Using Self-interest to Prevent Malice; 1805 Fixing the Denial of Service Flaw of the Internet," 1806 Workshop on the Economics of Securing the Information 1807 Infrastructure, October 2006. 1808 1810 [Bri07] Briscoe, B., "Flow Rate Fairness: Dismantling a 1811 Religion", ACM SIGCOMM Computer Communication Review, 1812 Vol.37, No.2, pp.63-74, April 2007. 1814 [Bri09] Briscoe, B., "Re-feedback: Freedom with Accountability 1815 for Causing Congestion in a Connectionless Internetwork," 1816 UCL PhD Thesis (2009). 1818 [Chester04] Chesterfield, J., Chakravorty, R., Banerjee, S., 1819 Rodriguez, P., Pratt, I., and Crowcroft, J., "Transport 1820 level optimisations for streaming media over wide-area 1821 wireless networks", WIOPT'04, March 2004. 1823 Open Research Issues in Internet Congestion Control Sep. 2010 1825 [Chiu89] Chiu, D.M., and R. Jain, "Analysis of the increase and 1826 decrease algorithms for congestion avoidance in computer 1827 networks", Computer Networks and ISDN Systems, Vol.17, 1828 pp.1-14, 1989. 1830 [Clark88] Clark, D., "The design philosophy of the DARPA internet 1831 protocols", ACM SIGCOMM Computer Communication Review, 1832 Vol.18, No.4, pp.106-114, August 1988. 1834 [Clark98] Clark, D., and W. Fang, "Explicit Allocation of Best- 1835 Effort Packet Delivery Service," IEEE/ACM Transactions 1836 on Networking, Vol.6, No.4, pp.362-373, August 1998. 1838 [Dukki05] Dukkipati, N., Kobayashi, M., Zhang-Shen, R. and N., 1839 McKeown, "Processor Sharing Flows in the Internet", 1840 Proceedings of International Workshop on QoS (IWQoS'05), 1841 Passau, Germany, June 2005. 1843 [Dukki06] Dukkipati, N. and N. McKeown, "Why Flow-Completion Time 1844 is the Right Metric for Congestion Control", ACM SIGCOMM 1845 Computer Communication Review, Vol.36, No.1, January 1846 2006. 1848 [ECN-tunnel] Briscoe, B., "Layered Encapsulation of Congestion 1849 Notification", Internet Draft, Work in progress, draft- 1850 ietf-tsvwg-ecn-tunnel. 1852 [ECODE] "ECODE Project", European Commission Seventh Framework 1853 Program, Grant No. 223936, 1855 [Falk07] Falk, A., et al., "Specification for the Explicit Control 1856 Protocol (XCP)", Internet draft, Work in Progress, draft- 1857 falk-xcp-spec-03.txt, July 2007. 1859 [Feldmann04] Feldmann, M., Papadimitriou, C., Chuang, J., I. Stoica, 1860 "FreeRiding and Whitewashing in Peer-to-Peer Systems" 1861 Proceedings of ACM SIGCOMM Workshop on Practice and 1862 Theory of Incentives in Networked Systems (PINS'04) 2004. 1863 . 1865 [Firoiu00] Firoiu, V., and M. Borden, "A Study of Active Queue 1866 Management for Congestion Control," Proceedings of IEEE 1867 INFOCOM'00, Tel Aviv, Israel, March 2000. 1869 [Floyd93] Floyd, S., and V. Jacobson, "Random early detection 1870 gateways for congestion avoidance," IEEE/ACM Transactions 1871 on Networking, Vol.1, No.4, pp.397-413, August 1993. 1873 [Floyd94] Floyd, S., "TCP and Explicit Congestion Notification", 1875 Open Research Issues in Internet Congestion Control Sep. 2010 1877 ACM Computer Communication Review, Vol.24, No.5, pp.10- 1878 23, October 1994. 1880 [Gibbens02] Gibbens, R. and Kelly, F., "On Packet Marking at Priority 1881 Queues," IEEE Transactions on Automatic Control, Vol.47, 1882 No.6, pp.1016-1020, 2002. 1884 [Ha08] Ha, S., Rhee, I., and L. Xu, "CUBIC: A new TCP-friendly 1885 high-speed TCP variant", ACM SIGOPS Operating System 1886 Review, Vol.42, No.5, pp.64-74, 2008. 1888 [Hollot01] Hollot, C., Misra, V., Towsley, D., and W.-B. Gong, "A 1889 Control Theoretic Analysis of RED," Proceedings of IEEE 1890 INFOCOM'01, Anchorage (Alaska), USA, April 2001. 1892 [Jacobson88] Jacobson, V., "Congestion Avoidance and Control", 1893 Proceeding of ACM SIGCOMM'88 Symposium, August 1988. 1895 [Jain88] Jain, R., and K. Ramakrishnan, "Congestion Avoidance in 1896 Computer Networks with a Connectionless Network Layer: 1897 Concepts, Goals, and Methodology", Proceedings of IEEE 1898 Computer Networking Symposium, Washington DC, USA, April 1899 1988. 1901 [Jain90] Jain, R., "Congestion Control in Computer Networks: 1902 Trends and Issues", IEEE Network, pp.24-30, May 1990. 1904 [Jin04] Jin, Ch., Wei, D.X., and S. Low, "FAST TCP: Motivation, 1905 Architecture, Algorithms, Performance," Proceedings of 1906 IEEE INFOCOM'04, Hong-Kong, China, March 2004. 1908 [Jourjon08] Jourjon, G., Emmanuel Lochin, E., and P. Senac, "Design, 1909 Implementation and Evaluation of a QoS-aware Transport 1910 Protocol", Elsevier, Computer Communications, Vol.31, 1911 No.9, pp.1713-1722, June 2008. 1913 [Katabi02] Katabi, D., M. Handley, and C. Rohr, "Internet Congestion 1914 Control for Future High Bandwidth-Delay Product 1915 Environments", Proceedings of ACM SIGCOMM'02 Symposium, 1916 August 2002. 1918 [Katabi04] Katabi, D., "XCP Performance in the Presence of Malicious 1919 Flows", Proceeding of PFLDnet'04 Workshop, Argonne 1920 (Illinois), USA, February 2004. 1922 [Kelly98] Kelly, F., Maulloo, A., and D. Tan, "Rate control in 1923 communication networks: shadow prices, proportional 1924 fairness, and stability," Journal of the Operational 1925 Research Society, Vol.49, pp.237-252, 1998. 1927 Open Research Issues in Internet Congestion Control Sep. 2010 1929 [Kelly05] Kelly, F., and Th. Voice, "Stability of end-to-end 1930 algorithms for joint routing and rate control", ACM 1931 SIGCOMM Computer Communication Review, Vol.35, No.2, pp. 1932 5-12, April 2005. 1934 [Keshav07] Keshav, S., "What is congestion and what is congestion 1935 control", Presentation at IRTF ICCRG Workshop, PFLDNet 1936 2007, Los Angeles (California), USA, February 2007. 1938 [Key04] Key, P., Massoulie, L., Bain, A., and F. Kelly, "Fair 1939 Internet Traffic Integration: Network Flow Models and 1940 Analysis", Annales des Telecommunications, Vol.59, No.11- 1941 12, pp.1338-1352, November-December 2004. 1943 [Krishnan04] Krishnan, R., Sterbenz, J., Eddy, W., Partridge, C., and 1944 M. Allman, "Explicit Transport Error Notification (ETEN) 1945 for Error-Prone Wireless and Satellite Networks", 1946 Computer Networks, Vol.46, No.3, October 2004. 1948 [Kuzmanovic03] Kuzmanovic, A., and E. W. Knightly, "TCP-LP: A 1949 Distributed Algorithm for Low Priority Data Transfer", 1950 Proceedings of IEEE INFOCOM'03, San Francisco 1951 (California), USA, April 2003. 1953 [LEDBAT] Shalunov, S., "Low Extra Delay Background Transport 1954 (LEDBAT)", Internet Draft, Work in progress, draft- 1955 shalunov-ledbat-congestion. 1957 [Lochin06] Lochin, E., Jourjon, G., and L. Dairaine, "Guaranteed TCP 1958 Friendly Rate Control (gTFRC) for DiffServ/AF Network" 1959 Internet Draft, Work in Progress, draft-lochin-ietf- 1960 tsvwg-gtfrc. 1962 [Lochin07] Lochin, E., Jourjon, G., and L. Dairaine, "Study and 1963 enhancement of DCCP over DiffServ Assured Forwarding 1964 class", 4th Conference on Universal Multiservice Networks 1965 (ECUMN 2007), Toulouse, France, February, 2007 1967 [Low02] Low, S., Paganini, F., Wang, J., Adlakha, S., and J.C. 1968 Doyle, "Dynamics of TCP/RED and a Scalable Control", 1969 Proceedings of IEEE INFOCOM'02, New York (New-Jersey), 1971 [Low03.1] Low, S., "A duality model of TCP and queue management 1972 algorithms", IEEE/ACM Transactions on Networking, Vol.11, 1973 No.4, pp.525-536, August 2003. 1975 [Low03.2] Low, S., Paganini, F., Wang, J., and J. Doyle, "Linear 1976 stability of TCP/RED and a scalable control", Computer 1977 Networks Journal, Vol.43, No.5, pp.633-647, December 1978 2003. 1980 Open Research Issues in Internet Congestion Control Sep. 2010 1982 [Low05] Low, S., Andrew, L., and B. Wydrowski, "Understanding 1983 XCP: equilibrium and fairness", Proceedings of IEEE 1984 INFOCOM'05, Miami (Florida), USA, March 2005. 1986 [LT-TCP] Tickoo, O., Subramanian, V., Kalyanaraman, S., and K.K. 1987 Ramakrishnan, "LT-TCP: End-to-End Framework to Improve 1988 TCP Performance over Networks with Lossy Channels", 1989 Proceedings of International Workshop on QoS (IWQoS) 1990 2005, Passau, Germany, June 2005. 1992 [Mascolo01] Mascolo, S., Casetti, Cl., Gerla M., Sanadidi, M.Y., and 1993 R. Wang, "TCP Westwood: Bandwidth estimation for enhanced 1994 transport over wireless links", Proceedings of MOBICOM 1995 2001. 1997 [Moors02] Moors, T., "A critical review of "End-to-end arguments in 1998 system design", Proceedings of IEEE International 1999 Conference on Communications (ICC) 2002, New-York City 2000 (New Jersey), USA, April/May 2002. 2002 [MKMV95] MacKie-Mason, J., and H. Varian, "Pricing Congestible 2003 Network Resources", IEEE Journal on Selected Areas in 2004 Communications, Advances in the Fundamentals of 2005 Networking, Vol.13, No.7, pp.1141-1149, 1995. 2007 [Padhye98] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, 2008 "Modeling TCP Throughput: A Simple Model and Its 2009 Empirical Validation", University of Massachusetts 2010 (UMass), CMPSCI Tech. Report TR98-008, February 1998. 2012 [Pan00] Pan, R., Prabhakar, B., and K. Psounis, "CHOKe: a 2013 stateless AQM scheme for approximating fair bandwidth 2014 allocation", Proceedings of IEEE INFOCOM'00, Tel Aviv, 2015 Israel, March 2000. 2017 [PAP02] Papadimitriou, I., and Mavromatis, G., "Stability of 2018 Congestion Control Algorithms using Control Theory with 2019 an application to XCP", Technical Report, 2002. 2020 2023 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2024 September 1981. 2026 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, 2027 RFC 793, September 1981. 2029 [RFC1323] Jacobson, V., Braden, R., and Borman, D., "TCP Extensions 2030 for High Performance", RFC 1323, May 1992. 2032 Open Research Issues in Internet Congestion Control Sep. 2010 2034 [RFC1701] Hanks, S., Li, T, Farinacci, D., and P. Traina, "Generic 2035 Routing Encapsulation", RFC 1701, October 1994. 2037 [RFC1958] Carpenter, B., Ed., "Architectural Principles of the 2038 Internet", RFC 1958, June 1996. 2040 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 1633, 2041 October 1996. 2043 [RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP 2044 Selective Acknowledgement Options", RFC 2018, October 2045 1996. 2047 [RFC2208] Mankin, A., Ed., et al. "Resource ReSerVation Protocol 2048 (RSVP) -- Version 1 Applicability Statement Some 2049 Guidelines on Deployment", RFC 2208, September 1997. 2051 [RFC2474] Nichols, K., Blake, S. Baker, F. and D. Black, 2052 "Definition of the Differentiated Services (DS) Field 2053 in the IPv4 and IPv6 Headers", RFC 2474, December 1998. 2055 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. 2056 and Weiss, W., "An Architecture for Differentiated 2057 Services", RFC 2475, December 1998. 2059 [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion 2060 Control", RFC 2581, April 1999. 2062 [RFC2637] Hamzeh, K., et al., "Point-to-Point Tunneling Protocol 2063 (PPTP)", RFC 2637, July, 1999. 2065 [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, 2066 G., and B. Palter, "Layer Two Tunneling Protocol (L2TP)", 2067 RFC 2661, August 1999. 2069 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 2070 February 2000. 2072 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. 2073 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 2074 March 2000. 2076 [RFC2861] Handley, M., J. Padhye, J., and S., Floyd, "TCP 2077 Congestion Window Validation", RFC 2861, June 2000. 2079 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, 2080 RFC 2914, September 2000. 2082 Open Research Issues in Internet Congestion Control Sep. 2010 2084 [RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", 2085 RFC 2990, November 2000. 2087 [RFC2988] Paxson, V., and Allman, M., "Computing TCP's 2088 Retransmission Timer", RFC 2988, November 2000. 2090 [RFC3031] Rosen, E., Viswanathan, A. and R. Callon, "Multiprotocol 2091 Label Switching Architecture", RFC 3031, January 2001. 2093 [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., 2094 Farinacci, D., Li, T. and A. Conta, "MPLS Label Stack 2095 Encoding", RFC 3032, January 2001. 2097 [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 2098 of Explicit Congestion Notification (ECN) to IP", 2099 RFC 3168, September 2001. 2101 [RFC3517] Blanton, E., Allman, M., Fall, K., et L. Wang, "A 2102 Conservative Selective Acknowledgment (SACK)-based 2103 Loss Recovery Algorithm for TCP", RFC 3517, April 2003. 2105 [RFC3540] Spring, N., and D. Wetherall, "Robust Explicit Congestion 2106 Notification (ECN) Signaling with Nonces", RFC 3540, June 2107 2003. 2109 [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort 2110 Per-Domain Behavior for Differentiated Services", RFC 2111 3662, December 2003. 2113 [RFC3714] Floyd, S., and J. Kempf, Eds. "IAB Concerns Regarding 2114 Congestion Control for Voice Traffic in the Internet", 2115 RFC 3714, March 2004. 2117 [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large 2118 Congestion Windows", RFC 3742, March 2004. 2120 [RFC3985] Bryant, S., and P. Pate, "Pseudo Wire Emulation Edge-to- 2121 Edge (PWE3) Architecture", RFC 3985, March 2005. 2123 [RFC4301] Kent, S., and K. Seo, "Security Architecture for the 2124 Internet Protocol", RFC 4301, December 2005. 2126 [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram 2127 Congestion Control Protocol (DCCP)", RFC 4340, March 2128 2006. 2130 [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion 2131 Control Protocol (DCCP) Congestion Control ID 2: TCP-like 2132 Congestion Control", RFC 4341, March 2006. 2134 Open Research Issues in Internet Congestion Control Sep. 2010 2136 [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for 2137 Datagram Congestion Control Protocol (DCCP) Congestion 2138 Control ID 3: TCP-Friendly Rate Control (TFRC)", RFC 2139 4342, March 2006. 2141 [RFC4553] Vainshtein, A., and Y. Stein, "Structure-Agnostic Time 2142 Division Multiplexing (TDM) over Packet (SAToP)", 2143 RFC 4553, June 2006. 2145 [RFC4614] Duke, M., R. Braden, R., Eddy, W., and E. Blanton, "A 2146 Roadmap for Transmission Control Protocol (TCP) 2147 Specification Documents", RFC 4614, September 2006. 2149 [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, 2150 "Quick-Start for TCP and IP", RFC 4782, January 2007. 2152 [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control 2153 (TFRC): The Small-Packet (SP) Variant", RFC 4828, April 2154 2007. 2156 [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the 2157 IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 2158 4948, August 2007. 2160 [RFC5033] Floyd, S., and M. Allman, "Specifying New Congestion 2161 Control Algorithms", RFC 5033, August 2007. 2163 [RFC5290] Floyd, S., and M. Allman, "Comments on the Usefulness of 2164 Simple Best-Effort Traffic", RFC 5290, July 2008. 2166 [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP 2167 Friendly Rate Control (TFRC): Protocol Specification", 2168 RFC 5348, September 2008. 2170 [RFC5405] Eggert, L., and G. Fairhurst, "Unicast UDP Usage 2171 Guidelines for Application Designers, RFC 5405, November 2172 2008. 2174 [RFC5622] Floyd, S., and E. Kohler, "Profile for Datagram 2175 Congestion Control Protocol (DCCP) Congestion ID 4: TCP- 2176 Friendly Rate Control for Small Packets (TFRC-SP)", RFC 2177 5622, August 2009. 2179 [RFC5681] Allman, M., Paxson, V., and Blanton, E., "TCP Congestion 2180 Control", RFC 5681 (Obsoletes RFC 2581), IETF, September 2181 2009. 2183 [RFC5783] Welzl, M., and W. Eddy, "Congestion Control in the RFC 2184 Series", RFC 5783, February 2010. 2186 Open Research Issues in Internet Congestion Control Sep. 2010 2188 [Rossi06] Rossi, M., "Evaluating TCP with Corruption Notification 2189 in an IEEE 802.11 Wireless LAN", Master Thesis, 2190 University of Innsbruck, November 2006. Available from 2191 2193 [Sarola07] Sarolahti, P., Floyd, S., and M. Kojo, "Transport-layer 2194 Considerations for Explicit Cross-layer Indications", 2195 Work in Progress, draft-sarolahti-tsvwg-crosslayer- 2196 01.txt, March 2007. 2198 [Savage99] Savage, S., Wetherall, D., and T. Anderson, "TCP 2199 Congestion Control with a Misbehaving Receiver," ACM 2200 SIGCOMM Computer Communication Review, 1999. 2202 [Saltzer84] Saltzer, J., Reed, D., and D. Clark, "End-to-end 2203 arguments in system design", ACM Transactions on Computer 2204 Systems, Vol.2, No.4, November 1984. 2206 [Shin08] Shin, M., Chong, S., and I. Rhee, "Dual-Resource TCP/AQM 2207 for Processing-Constrained Networks", IEEE/ACM 2208 Transactions on Networking, Vol.16, No.2, pp.435-449, 2209 April 2008. 2211 [SK02] Sarolahti, P., and M. Kojo, "F-RTO: A TCP RTO Recovery 2212 Algorithm for Avoiding Unnecessary Retransmissions", 2213 Internet-Draft, draft-sarolahti-tsvwg-tcp-frto-02.txt, 2214 November 2002, Work in progress. 2216 [Tickoo05] Subramanian, V., Kalyanaraman, S. and Ramakrishnan, K., 2217 "LT-TCP: End-to-End Framework to Improve TCP Performance 2218 over Networks with Lossy Channels," Proc. International 2219 Workshop on QoS (IWQoS'05), June 2005. 2221 [Thaler07] Thaler, D., Sridhara, M., and D. Bansal, "Implementation 2222 Report on Experiences with Various TCP RFCs", 2223 Presentation to the IETF Transport Area, March 2007. 2224 2226 [TRILOGY] "Trilogy Project", European Commission Seventh Framework 2227 Program (FP7), Grant No: 216372 2228 2230 [Welzl03] Welzl, M., "Scalable Performance Signalling and 2231 Congestion Avoidance", Springer (ISBN 1-4020-7570-7), 2232 August 2003. 2234 [Welzl08] Welzl, M., Rossi, M., Fumagalli, A., and M. Tacca, 2235 "TCP/IP over IEEE 802.11b WLAN: the Challenge of 2236 Harnessing Known-Corrupt Data", Proceedings of IEEE 2238 Open Research Issues in Internet Congestion Control Sep. 2010 2240 International Conference on Communications (ICC) 2008, 2241 Beijing, China, May 2008. 2243 [Xia05] Xia, Y., Subramanian, L., Stoica, I., and S.Kalyanaraman, 2244 "One more bit is enough", ACM SIGCOMM Computer 2245 Communication Review, Vol.35, No.4, pp.37-48, 2005. 2247 [Zhang03] Zhang, H., Hollot, C., Towsley, D., and V. Misra, "A 2248 Self-Tuning Structure for Adaptation in TCP/AQM 2249 Networks", Proceedings of ACM SIGMETRICS'03 Conference, 2250 San Diego (California), USA, June 2003. 2252 Open Research Issues in Internet Congestion Control Sep. 2010 2254 7. Acknowledgments 2256 The authors would like to thank the following people whose feedback 2257 and comments contributed to this document: Keith Moore, Jan 2258 Vandenabeele, and Larry Dunn (his comments at the Manchester ICCRG 2259 and discussions with him helped with the section on packet- 2260 congestibility). 2262 Dimitri Papadimitriou's contribution was partly funded by [ECODE], a 2263 Seventh Framework Program (FP7) research project sponsored by the 2264 European Commission. 2266 Bob Briscoe's contribution was partly funded by [TRILOGY], a research 2267 project supported by the European Commission. 2269 Michael Scharf is now with Alcatel-Lucent. 2271 8. Author's Addresses 2273 Dimitri Papadimitriou (Editor) 2274 Alcatel-Lucent 2275 Copernicuslaan, 50 2276 2018 Antwerpen, Belgium 2277 Phone: +32 3 240 8491 2278 Email: dimitri.papadimitriou@alcatel-lucent.be 2280 Michael Welzl 2281 University of Oslo, Department of Informatics 2282 PO Box 1080 Blindern 2283 N-0316 Oslo, Norway 2284 Email: michawe@ifi.uio.no 2286 Michael Scharf 2287 University of Stuttgart 2288 Pfaffenwaldring 47 2289 70569 Stuttgart, Germany 2290 Email: michael.scharf@googlemail.com 2292 Bob Briscoe 2293 BT & UCL 2294 B54/77, Adastral Park 2295 Martlesham Heath 2296 Ipswich IP5 3RE, UK 2297 Email: bob.briscoe@bt.com 2299 9. Contributors 2301 The following additional people have contributed to this document: 2302 - Wesley Eddy 2303 - Bela Berde 2304 - Paulo Loureiro 2305 - Chris Christou 2307 Open Research Issues in Internet Congestion Control Sep. 2010 2309 Full Copyright Statement 2311 Copyright (c) 2010 IETF Trust and the persons identified as the 2312 document authors. All rights reserved. 2314 This document is subject to BCP 78 and the IETF Trust's Legal 2315 Provisions Relating to IETF Documents 2316 (http://trustee.ietf.org/license-info) in effect on the date of 2317 publication of this document. Please review these documents 2318 carefully, as they describe your rights and restrictions with respect 2319 to this document. Code Components extracted from this document must 2320 include Simplified BSD License text as described in Section 4.e of 2321 the Trust Legal Provisions and are provided without warranty as 2322 described in the BSD License. 2324 This document may contain material from IETF Documents or IETF 2325 Contributions published or made publicly available before November 2326 10, 2008. The person(s) controlling the copyright in some of this 2327 material may not have granted the IETF Trust the right to allow 2328 modifications of such material outside the IETF Standards Process. 2329 Without obtaining an adequate license from the person(s) controlling 2330 the copyright in such materials, this document may not be modified 2331 outside the IETF Standards Process, and derivative works of it may 2332 not be created outside the IETF Standards Process, except to format 2333 it for publication as an RFC or to translate it into languages other 2334 than English. 2336 Acknowledgments 2338 Funding for the RFC Editor function is provided by the IETF 2339 Administrative Support Activity (IASA).