diff options
Diffstat (limited to 'doc/rfc/rfc6077.txt')
| -rw-r--r-- | doc/rfc/rfc6077.txt | 2859 |
1 files changed, 2859 insertions, 0 deletions
diff --git a/doc/rfc/rfc6077.txt b/doc/rfc/rfc6077.txt new file mode 100644 index 0000000..33a5d6c --- /dev/null +++ b/doc/rfc/rfc6077.txt @@ -0,0 +1,2859 @@ + + + + + + +Internet Research Task Force (IRTF) D. Papadimitriou, Ed. +Request for Comments: 6077 Alcatel-Lucent +Category: Informational M. Welzl +ISSN: 2070-1721 University of Oslo + M. Scharf + University of Stuttgart + B. Briscoe + BT & UCL + February 2011 + + + Open Research Issues in Internet Congestion Control + +Abstract + + This document describes some of the open problems in Internet + congestion control that are known today. This includes several new + challenges that are becoming important as the network grows, as well + as some issues that have been known for many years. These challenges + are generally considered to be open research topics that may require + more study or application of innovative techniques before Internet- + scale solutions can be confidently engineered and deployed. + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Research Task Force + (IRTF). The IRTF publishes the results of Internet-related research + and development activities. These results might not be suitable for + deployment. This RFC represents the consensus of the Internet + Congestion Control Research Group (ICCRG) of the Internet Research + Task Force (IRTF). Documents approved for publication by the IRSG + are not a candidate for any level of Internet Standard; see Section 2 + of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6077. + + + + + + + + + + + +Papadimitriou, et al. Informational [Page 1] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + +Copyright Notice + + Copyright (c) 2011 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Papadimitriou, et al. Informational [Page 2] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Global Challenges ...............................................5 + 2.1. Heterogeneity ..............................................5 + 2.2. Stability ..................................................7 + 2.3. Fairness ...................................................8 + 3. Detailed Challenges ............................................10 + 3.1. Challenge 1: Network Support ..............................10 + 3.1.1. Performance and Robustness .........................14 + 3.1.2. Granularity of Network Component Functions .........15 + 3.1.3. Information Acquisition ............................16 + 3.1.4. Feedback Signaling .................................17 + 3.2. Challenge 2: Corruption Loss ..............................17 + 3.3. Challenge 3: Packet Size ..................................19 + 3.4. Challenge 4: Flow Startup .................................24 + 3.5. Challenge 5: Multi-Domain Congestion Control ..............26 + 3.5.1. Multi-Domain Transport of Explicit + Congestion Notification ............................26 + 3.5.2. Multi-Domain Exchange of Topology or + Explicit Rate Information ..........................27 + 3.5.3. Multi-Domain Pseudowires ...........................28 + 3.6. Challenge 6: Precedence for Elastic Traffic ...............30 + 3.7. Challenge 7: Misbehaving Senders and Receivers ............31 + 3.8. Other Challenges ..........................................33 + 3.8.1. RTT Estimation .....................................33 + 3.8.2. Malfunctioning Devices .............................35 + 3.8.3. Dependence on RTT ..................................36 + 3.8.4. Congestion Control in Multi-Layered Networks .......36 + 3.8.5. Multipath End-to-End Congestion Control and + Traffic Engineering ................................37 + 3.8.6. ALGs and Middleboxes ...............................37 + 4. Security Considerations ........................................38 + 5. References .....................................................39 + 5.1. Informative References ....................................39 + 6. Acknowledgments ................................................50 + 7. Contributors ...................................................50 + +1. Introduction + + This document, the result of the Internet Congestion Control Research + Group (ICCRG), describes some of the open research topics in the + domain of Internet congestion control that are known today. We begin + by reviewing some proposed definitions of congestion and congestion + control based on current understandings. + + + + + + +Papadimitriou, et al. Informational [Page 3] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + Congestion can be defined as a state or condition that occurs when + network resources are overloaded, resulting in impairments for + network users as objectively measured by the probability of loss + and/or delay. The overload results in the reduction of utility in + networks that support both spatial and temporal multiplexing, but no + reservation [Keshav07]. Congestion control is a (typically + distributed) algorithm to share network resources among competing + traffic sources. + + Two components of distributed congestion control have been defined in + the context of primal-dual modeling [Kelly98]. Primal congestion + control refers to the algorithm executed by the traffic sources for + controlling their sending rates or window sizes. This is normally a + closed-loop control, where this operation depends on feedback. TCP + algorithms fall in this category. Dual congestion control is + implemented by the routers through gathering information about the + traffic traversing them. A dual congestion control algorithm + updates, implicitly or explicitly, a congestion measure or congestion + rate and sends it back, implicitly or explicitly, to the traffic + sources that use that link. Queue management algorithms such as + Random Early Detection (RED) [Floyd93] or Random Exponential Marking + (REM) [Ath01] fall into the "dual" category. + + Congestion control provides for a fundamental set of mechanisms for + maintaining the stability and efficiency of the Internet. Congestion + control has been associated with TCP since Van Jacobson's work in + 1988, but there is also congestion control outside of TCP (e.g., for + real-time multimedia applications, multicast, and router-based + mechanisms) [RFC5783]. The Van Jacobson end-to-end congestion + control algorithms [Jacobson88] [RFC2581] [RFC5681] are used by the + Internet transport protocol TCP [RFC4614]. They have been proven to + be highly successful over many years but have begun to reach their + limits, as the heterogeneity of the data link and physical layer on + the one hand, and of applications on the other, are pulling TCP + congestion control beyond its natural operating regime. This is + because it performs poorly as the bandwidth or delay increases. A + side effect of these deficiencies is that an increasing share of + hosts use non-standardized congestion control enhancements (for + instance, many Linux distributions have been shipped with "CUBIC" + [Ha08] as the default TCP congestion control mechanism). + + While the original Van Jacobson algorithm requires no congestion- + related state in routers, more recent modifications have departed + from the strict application of the end-to-end principle [Saltzer84] + in order to avoid congestion collapse. Active Queue Management (AQM) + in routers, e.g., RED and some of its variants such as Adaptive RED + (ARED), improves performance by keeping queues small (implicit + feedback via dropped packets), while Explicit Congestion Notification + + + +Papadimitriou, et al. Informational [Page 4] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + (ECN) [Floyd94] [RFC3168] passes one bit of congestion information + back to senders when an AQM would normally drop a packet. It is to + be noted that other variants of RED built on AQM, such as Weighted + RED (WRED) and RED with In/Out (RIO) [Clark98] are for quality + enforcement, whereas Stabilized RED (SRED), and CHOKe [Pan00] and its + extensions such as XCHOKe [Chhabra02], are flow policers. In + [Bonald00], authors analytically evaluated RED performance. + + These measures do improve performance, but there is a limit to how + much can be accomplished without more information from routers. The + requirement of extreme scalability together with robustness has been + a difficult hurdle for acceleration of this information flow. + Primal-dual TCP/AQM distributed algorithm stability and equilibrium + properties have been extensively studied (cf. [Low02], [Low03.1], + [Low03.2], [Kelly98], and [Kelly05]). + + Congestion control includes many new challenges that are becoming + important as the network grows, in addition to the issues that have + been known for many years. These are generally considered to be open + research topics that may require more study or application of + innovative techniques before Internet-scale solutions can be + confidently engineered and deployed. In what follows, an overview of + some of these challenges is given. + +2. Global Challenges + + This section describes the global challenges to be addressed in the + domain of Internet congestion control. + +2.1. Heterogeneity + + The Internet encompasses a large variety of heterogeneous IP networks + that are realized by a multitude of technologies, which result in a + tremendous variety of link and path characteristics: capacity can be + either scarce in very-slow-speed radio links (several kbps), or there + may be an abundant supply in high-speed optical links (several + gigabit per second). Concerning latency, scenarios range from local + interconnects (much less than a millisecond) to certain wireless and + satellite links with very large latencies up to or over a second). + Even higher latencies can occur in space communication. As a + consequence, both the available bandwidth and the end-to-end delay in + the Internet may vary over many orders of magnitude, and it is likely + that the range of parameters will further increase in the future. + + Additionally, neither the available bandwidth nor the end-to-end + delay is constant. At the IP layer, competing cross-traffic, traffic + management in routers, and dynamic routing can result in sudden + changes in the characteristics of an end-to-end path. Additional + + + +Papadimitriou, et al. Informational [Page 5] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + dynamics can be caused by link layer mechanisms, such as shared-media + access (e.g., in wireless networks), changes to new links due to + mobility (horizontal/vertical handovers), topology modifications + (e.g., in ad hoc or meshed networks), link layer error correction, + and dynamic bandwidth provisioning schemes. From this, it follows + that path characteristics can be subject to substantial changes + within short time frames. + + Congestion control algorithms have to deal with this variety in an + efficient and stable way. The congestion control principles + introduced by Van Jacobson assume a rather static scenario and + implicitly target configurations where the bandwidth-delay product is + of the order of some dozens of packets at most. While these + principles have proved to work in the Internet for almost two + decades, much larger bandwidth-delay products and increased dynamics + challenge them more and more. There are many situations where + today's congestion control algorithms react in a suboptimal way, + resulting, among other things, in low resource utilization. + + This has resulted in a multitude of new proposals for congestion + control algorithms. For instance, since the Additive Increase + Multiplicative Decrease (AIMD) behavior of TCP is too conservative in + practical environments when the congestion window is large, several + high-speed congestion control extensions have been developed. + However, these new algorithms may be less robust or starve legacy + flows in certain situations for which they have not been designed. + At the time of writing, there is no common agreement in the IETF on + which algorithm(s) and protocol(s) to choose. + + It is always possible to tune congestion control parameters based on + some knowledge of the environment and the application scenario. + However, the interaction between multiple congestion control + techniques is not yet well understood. The fundamental challenge is + whether it is possible to define one congestion control mechanism + that operates reasonably well in a whole range of scenarios that + exist in the Internet. Hence, important research questions are how + new Internet congestion control mechanisms would have to be designed, + which maximum degree of dynamics they can efficiently handle, and + whether they can keep the generality of the existing end-to-end + solutions. + + Some improvements to congestion control could be realized by simple + changes to single functions in end-systems or optimizations of + network components. However, new mechanism(s) might also require a + fundamental redesign of the overall network architecture, and they + may even affect the design of Internet applications. This can imply + significant interoperability and backward compatibility challenges + and/or create network accessibility obstacles. In particular, + + + +Papadimitriou, et al. Informational [Page 6] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + networks and/or applications that do not use or support a new + congestion control mechanism could be penalized by a significantly + worse performance compared to what they would get if everybody used + the existing mechanisms (cf. the discussion on fairness in + Section 2.3). [RFC5033] defines several criteria to evaluate the + appropriateness of a new congestion control mechanism. However, a + key issue is how much performance deterioration is acceptable for + "legacy" applications. This tradeoff between performance and cost + has to be very carefully examined for all new congestion control + schemes. + +2.2. Stability + + Control theory is a mathematical tool for describing dynamic systems. + It lends itself to modeling congestion control -- TCP is a perfect + example of a typical "closed loop" system that can be described in + control theoretic terms. However, control theory has had to be + extended to model the interactions between multiple control loops in + a network [Vinnic02]. In control theory, there is a mathematically + defined notion of system stability. In a stable system, for any + bounded input over any amount of time, the output will also be + bounded. For congestion control, what is actually meant by global + stability is typically asymptotic stability: a mechanism should + converge to a certain state irrespective of the initial state of the + network. Local stability means that if the system is perturbed from + its stable state it will quickly return toward the locally stable + state. + + Some fundamental facts known from control theory are useful as + guidelines when designing a congestion control mechanism. For + instance, a controller should only be fed a system state that + reflects its output. A (low-pass) filter function should be used in + order to pass to the controller only states that are expected to last + long enough for its action to be meaningful [Jain88]. Action should + be carried out whenever such feedback arrives, as it is a fundamental + principle of control that the control frequency should ideally be + equal to the feedback frequency. Reacting faster leads to + oscillations and instability, while reacting more slowly makes the + system tardy [Jain90]. + + Control theoretic modeling of a realistic network can be quite + difficult, especially when taking distinct packet sizes and + heterogeneous round-trip times (RTTs) into account. It has therefore + become common practice to model simpler cases and to leave the more + complicated (realistic) situations for simulations. Clearly, if a + mechanism is not stable in a simple scenario, it is generally + useless; this method therefore helps to eliminate faulty congestion + control candidates at an early stage. However, a mechanism that is + + + +Papadimitriou, et al. Informational [Page 7] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + found to be stable in simulations can still not be safely deployed in + real networks, since simulation scenarios make simplifying + assumptions. + + TCP stability can be attributed to two key aspects that were + introduced in [Jacobson88]: the AIMD control law during congestion + avoidance, which is based on a simple, vector-based analysis of two + controllers sharing one resource with synchronous RTTs [Chiu89]; and + the "conservation of packets principle", which, once the control has + reached "steady state", tries to maintain an equal amount of packets + in flight at any time by only sending a packet into the network when + a packet has left the network (as indicated by an ACK arriving at the + sender). The latter aspect has guided many decisions regarding + changes that were made to TCP over the years. + + The reasoning in [Jacobson88] assumes all senders to be acting at the + same time. The stability of TCP under more realistic network + conditions has been investigated in a large number of ensuing works, + leading to no clear conclusion that TCP would also be asymptotically + stable under arbitrary network conditions. On the other hand, + research has concluded that stability can be assured with constraints + on dynamics that are less stringent than the "conservation of packets + principle". From control theory, only rate increase (not the target + rate) needs to be inversely proportional to RTT (whereas window-based + control converges on a target rate inversely proportional to RTT). A + congestion control mechanism can therefore converge on a rate that is + independent of RTT as long as its dynamics depend on RTT (e.g., FAST + TCP [Jin04]). + + In the stability analysis of TCP and of these more modern controls, + the impact of slow-start on stability (which can be significant as + short-lived HTTP flows often never leave this phase) is not entirely + clear. + +2.3. Fairness + + Recently, the way the Internet community reasons about fairness has + been called deeply into question [Bri07]. Much of the community has + taken fairness to mean approximate equality between the rates of + flows (flow rate fairness) that experience equivalent path congestion + as with TCP [RFC2581] [RFC5681] and TCP-Friendly Rate Control (TFRC) + [RFC5348]. [RFC3714] depicts the resulting situation as "The + Amorphous Problem of Fairness". + + + + + + + + +Papadimitriou, et al. Informational [Page 8] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + A parallel tradition has been built on [Kelly98] where, as long as + each user is accountable for the cost their rate causes to others + [MacK95], the set of rates that everyone chooses is deemed fair (cost + fairness) -- because with any other set of choices people would lose + more value than they gained overall. + + In comparison, the debate between max-min, proportional, and TCP + fairness is about mere details. These three all share the assumption + that equal flow rates are desirable; they merely differ in the + second-order issue of how to share out excess capacity in a network + of many bottlenecks. In contrast, cost fairness should lead to + extremely unequal flow rates by design. Equivalently, equal flow + rates would typically be considered extremely unfair. + + The two traditional approaches are not protocol options that can each + be followed in different parts of an internetwork. They lead to + research agendas that are different in their respective objectives, + resulting in a different set of open issues. + + If we assume TCP-friendliness as a goal with flow rate as the metric, + open issues would be: + + - Should flow fairness depend on the packet rate or the bit rate? + + - Should the target flow rate depend on RTT (as in TCP) or should + only flow dynamics depend on RTT (e.g., as in FAST TCP [Jin04])? + + - How should we estimate whether a particular flow start strategy is + fair, or whether a particular fast recovery strategy after a + reduction in rate due to congestion is fair? + + - Should we judge what is reasonably fair if an application needs, + for example, even smoother flows than TFRC, or it needs to burst + occasionally, or with any other application behavior? + + - During brief congestion bursts (e.g., due to new flow arrivals), + how should we judge at what point it becomes unfair for some flows + to continue at a smooth rate while others reduce their rate? + + - Which mechanism(s) could be used to enforce approximate flow rate + fairness? + + - Should we introduce some degree of fairness that takes into + account different users' flow activity over time? + + - How should we judge the fairness of applications using a large + number of flows over separate paths (e.g., via an overlay)? + + + + +Papadimitriou, et al. Informational [Page 9] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + If we assume cost fairness as a goal with congestion-volume as the + metric, open issues would be: + + - Can one application's sensitivity to instantaneous congestion + really be protected by longer-term accountability of competing + applications? + + - Which protocol mechanism(s) are needed to give accountability for + causing congestion? + + - How might we design one or two weighted transport protocols (such + as TCP, UDP, etc.) with the addition of application policy control + over the weight? + + - Which policy enforcement might be used by networks, and what are + the interactions between application policy and network policy + enforcement? + + - How should we design a new policy enforcement framework that will + appropriately compete with existing flows aiming for rate equality + (e.g., TCP)? + + The question of how to reason about fairness is a prerequisite to + agreeing on the research agenda. If the relevant metric is flow + rate, it places constraints at protocol design time, whereas if the + metric is congestion-volume, the constraints move to run-time while + design-time constraints can be relaxed [Bri08]. However, that + question does not require more research in itself; it is merely a + debate that needs to be resolved by studying existing research and by + assessing how bad fairness problems could become if they are not + addressed rigorously, and whether we can rely on trust to maintain + approximate fairness without requiring policing complexity [RFC5290]. + The latter points may themselves lead to additional research. + However, it is also accepted that more research will not necessarily + lead to convincing either side to change their opinions. More debate + would be needed. It seems also that if the architecture is built to + support cost fairness, then equal instantaneous cost rates for flows + sharing a bottleneck result in flow-rate fairness; that is, flow-rate + fairness can be seen as a special case of cost fairness. One can be + used to build the other, but not vice-versa. + +3. Detailed Challenges + +3.1. Challenge 1: Network Support + + This challenge is perhaps the most critical to get right. Changes to + the balance of functions between the endpoints and network equipment + could require a change to the per-datagram data plane interface + + + +Papadimitriou, et al. Informational [Page 10] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + between the transport and network layers. Network equipment vendors + need to be assured that any new interface is stable enough (on decade + timescales) to build into firmware and hardware, and operating-system + vendors will not use a new interface unless it is likely to be widely + deployed. + + Network components can be involved in congestion control in two ways: + first, they can implicitly optimize their functions, such as queue + management and scheduling strategies, in order to support the + operation of end-to-end congestion control. Second, network + components can participate in congestion control via explicit + signaling mechanisms. Explicit signaling mechanisms, whether in-band + or out-of-band, require a communication between network components + and end-systems. Signals realized within or over the IP layer are + only meaningful to network components that process IP packets. This + always includes routers and potentially also middleboxes, but not + pure link layer devices. The following section distinguishes clearly + between the term "network component" and the term "router"; the term + "router" is used whenever the processing of IP packets is explicitly + required. One fundamental challenge of network-supported congestion + control is that typically not all network components along a path are + routers (cf. Section 3.1.3). + + The first (optimizing) category of implicit mechanisms can be + implemented in any network component that processes and stores + packets. Various approaches have been proposed and also deployed, + such as different AQM techniques. Even though these implicit + techniques are known to improve network performance during congestion + phases, they are still only partly deployed in the Internet. This + may be due to the fact that finding optimal and robust + parameterizations for these mechanisms is a non-trivial problem. + Indeed, the problem with various AQM schemes is the difficulty in + identifying correct values of the parameters that affect the + performance of the queuing scheme (due to variation in the number of + sources, the capacity, and the feedback delay) [Firoiu00] [Hollot01] + [Zhang03]. Many AQM schemes (RED, REM, BLUE, and PI-Controller, but + also Adaptive Virtual Queue (AVQ)) do not define a systematic rule + for setting their parameters. + + The second class of approaches uses explicit signaling. By using + explicit feedback from the network, connection endpoints can obtain + more accurate information about the current network characteristics + on the path. This allows endpoints to make more precise decisions + that can better control congestion. + + + + + + + +Papadimitriou, et al. Informational [Page 11] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + Explicit feedback techniques fall into three broad categories: + + - Explicit congestion feedback: one-bit Explicit Congestion + Notification (ECN) [RFC3168] or proposals for more than one bit + [Xia05]; + + - Explicit per-datagram rate feedback: the eXplicit Control Protocol + (XCP) [Katabi02] [Falk07], or the Rate Control Protocol (RCP) + [Dukki05]; + + - Explicit rate feedback: by means of in-band signaling, such as by + Quick-Start [RFC4782], or by means of out-of-band signaling, e.g., + Congestion Avoidance with Distributed Proportional + Control/Performance Transparency Protocol (CADPC/PTP) [Welzl03]. + + Explicit router feedback can address some of the inherent + shortcomings of TCP. For instance, XCP was developed to overcome the + inefficiency and instability that TCP suffers from when the per-flow + bandwidth-delay product increases. By decoupling resource + utilization/congestion control from fairness control, XCP achieves + equal bandwidth allocation, high utilization, a small standing queue + size, and near-zero packet drops, with both steady and highly varying + traffic. Importantly, XCP does not maintain any per-flow state in + routers and requires few CPU cycles per packet, hence making it + potentially applicable in high-speed routers. However, XCP is still + subject to research: as [Andrew05] has pointed out, XCP is locally + stable but globally unstable when the maximum RTT of a flow is much + larger than the mean RTT. This instability can be removed by + changing the update strategy for the estimation interval, but this + makes the system vulnerable to erroneous RTT advertisements. The + authors of [Pap02] have shown that when flows with different RTTs are + applied, XCP sometimes discriminates among heterogeneous traffic + flows, even if XCP generally equalizes rates among different flows. + [Low05] provides for a complete characterization of the XCP + equilibrium properties. + + Several other explicit router feedback schemes have been developed + with different design objectives. For instance, RCP uses per-packet + feedback similar to XCP. But unlike XCP, RCP focuses on the + reduction of flow completion times [Dukki06], taking an optimistic + approach to flows likely to arrive in the next RTT and tolerating + larger instantaneous queue sizes [Dukki05]. XCP, on the other hand, + gives very poor flow completion times for short flows. + + Both implicit and explicit router support should be considered in the + context of the end-to-end argument [Saltzer84], which is one of the + key design principles of the Internet. It suggests that functions + that can be realized both in the end-systems and in the network + + + +Papadimitriou, et al. Informational [Page 12] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + should be implemented in the end-systems. This principle ensures + that the network provides a general service and that it remains as + simple as possible (any additional complexity is placed above the IP + layer, i.e., at the edges) so as to ensure evolvability, reliability, + and robustness. Furthermore, the fate-sharing principle ([Clark88], + "Design Philosophy of the DARPA Internet Protocols") mandates that an + end-to-end Internet protocol design should not rely on the + maintenance of any per-flow state (i.e., information about the state + of the end-to-end communication) inside the network and that the + network state (e.g., routing state) maintained by the Internet shall + minimize its interaction with the states maintained at the + endpoints/hosts [RFC1958]. + + However, as discussed in [Moors02] for instance, congestion control + cannot be realized as a pure end-to-end function only. Congestion is + an inherent network phenomenon and can only be resolved efficiently + by some cooperation of end-systems and the network. Congestion + control in today's Internet protocols follows the end-to-end design + principle insofar as only minimal feedback from the network is used, + e.g., packet loss and delay. The end-systems only decide how to + react and how to avoid congestion. The crux is that on the one hand, + there would be substantial benefit by further assistance from the + network, but, on the other hand, such network support could lead to + duplication of functions, which might even harmfully interact with + end-to-end protocol mechanisms. The different requirements of + applications (cf. the fairness discussion in Section 2.3) call for a + variety of different congestion control approaches, but putting such + per-flow behavior inside the network should be avoided, as such a + design would clearly be at odds with the end-to-end and fate-sharing + design principles. + + The end-to-end and fate-sharing principles are generally regarded as + the key ingredients for ensuring a scalable and survivable network + design. In order to ensure that new congestion control mechanisms + are scalable, violating these principles must therefore be avoided. + + For instance, protocols like XCP and RCP seem not to require flow + state in the network, but this is only the case if the network trusts + i) the receiver not to lie when feeding back the network's delta to + the requested rate; ii) the source not to lie when declaring its + rate; and iii) the source not to cheat when setting its rate in + response to the feedback [Katabi04]. + + + + + + + + + +Papadimitriou, et al. Informational [Page 13] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + Solving these problems for non-cooperative environments like the + public Internet requires flow state, at least on a sampled basis. + However, because flows can create new identifiers whenever they want, + sampling does not provide a deterrent -- a flow can simply cheat + until it is discovered and then switch to a whitewashed identifier + [Feldman04], and continue cheating until it is discovered again + ([Bri09], S7.3). + + However, holding flow state in the network only seems to solve these + policing problems in single autonomous system settings. A + multi-domain system would seem to require a completely different + protocol structure, as the information required for policing is only + seen as packets leave the internetwork, but the networks where + packets enter will also want to police compliance. + + Even if a new protocol structure were found, it seems unlikely that + network flow state could be avoided given the network's per-packet + flow rate instructions would need to be compared against variations + in the actual flow rate, which is inherently not a per-packet metric. + These issues have been outstanding ever since integrated services + (IntServ) was identified as unscalable in 1997 [RFC2208]. All + subsequent attempts to involve network elements in limiting flow + rates (XCP, RCP, etc.) will run up against the same open issue if + anyone attempts to standardize them for use on the public Internet. + + In general, network support of congestion control raises many issues + that have not been completely solved yet. + +3.1.1. Performance and Robustness + + Congestion control is subject to some tradeoffs: on the one hand, it + must allow high link utilizations and fair resource sharing, but on + the other hand, the algorithms must also be robust. + + Router support can help to improve performance, but it can also + result in additional complexity and more control loops. This + requires a careful design of the algorithms in order to ensure + stability and avoid, e.g., oscillations. A further challenge is the + fact that feedback information may be imprecise. For instance, + severe congestion can delay feedback signals. Also, in-network + measurement of parameters such as RTTs or data rates may contain + estimation errors. Even though there has been significant progress + in providing fundamental theoretical models for such effects, + research has not completely explored the whole problem space yet. + + + + + + + +Papadimitriou, et al. Informational [Page 14] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + Open questions are: + + - How much can network elements theoretically improve performance in + the complete range of communication scenarios that exist in the + Internet without damaging or impacting end-to-end mechanisms + already in place? + + - Is it possible to design robust congestion control mechanisms that + offer significant benefits with minimum additional risks, even if + Internet traffic patterns will change in the future? + + - What is the minimum support that is needed from the network in + order to achieve significantly better performance than with end- + to-end mechanisms and the current IP header limitations that + provide at most unary ECN signals? + +3.1.2. Granularity of Network Component Functions + + There are several degrees of freedom concerning the involvement of + network entities, ranging from some few additional functions in + network management procedures on the one end to additional per-packet + processing on the other end of the solution space. Furthermore, + different amounts of state can be kept in routers (no per-flow state, + partial per-flow state, soft state, or hard state). The additional + router processing is a challenge for Internet scalability and could + also increase end-to-end latencies. + + Although there are many research proposals that do not require + per-flow state and thus do not cause a large processing overhead, + there are no known full solutions (i.e., including anti-cheating) + that do not require per-flow processing. Also, scalability issues + could be caused, for instance, by synchronization mechanisms for + state information among parallel processing entities, which are, + e.g., used in high-speed router hardware designs. + + Open questions are: + + - What granularity of router processing can be realized without + affecting Internet scalability? + + - How can additional processing efforts be kept to a minimum? + + + + + + + + + + +Papadimitriou, et al. Informational [Page 15] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + +3.1.3. Information Acquisition + + In order to support congestion control, network components have to + obtain at least a subset of the following information. Obtaining + that information may result in complex tasks. + + 1. Capacity of (outgoing) links + + Link characteristics depend on the realization of lower protocol + layers. Routers operating at the IP layer do not necessarily know + the link layer network topology and link capacities, and these are + not always constant (e.g., on shared wireless links or bandwidth- + on-demand links). Depending on the network technology, there can + be queues or bottlenecks that are not directly visible at the IP + networking layer. + + Difficulties also arise when using IP-in-IP tunnels [RFC2003], + IPsec tunnels [RFC4301], IP encapsulated in the Layer Two + Tunneling Protocol (L2TP) [RFC2661], Generic Routing Encapsulation + (GRE) [RFC1701] [RFC2784], the Point-to-Point Tunneling Protocol + (PPTP) [RFC2637], or Multiprotocol Label Switching (MPLS) + [RFC3031] [RFC3032]. In these cases, link information could be + determined by cross-layer information exchange, but this requires + interfaces capable of processing link layer technology specific + information. An alternative could be online measurements, but + this can cause significant additional network overhead. It is an + open research question as to how much, if any, online traffic + measurement would be acceptable (at run-time). Encapsulation and + decapsulation of explicit congestion information have been + specified for IP-in-IP tunnelling [RFC6040] and for MPLS-in-MPLS + or MPLS-in-IP [RFC5129]. + + 2. Traffic carried over (outgoing) links + + Accurate online measurement of data rates is challenging when + traffic is bursty. For instance, measuring a "current link load" + requires defining the right measurement interval / sampling + interval. This is a challenge for proposals that require + knowledge, e.g., about the current link utilization. + + 3. Internal buffer statistics + + Some proposals use buffer statistics such as a virtual queue + length to trigger feedback. However, network components can + include multiple distributed buffer stages that make it difficult + to obtain such metrics. + + + + + +Papadimitriou, et al. Informational [Page 16] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + Open questions are: + + - Can and should this information be made available, e.g., by + additional interfaces or protocols? + + - Which information is so important to higher-layer controllers that + machine architecture research should focus on designing to + provide it? + +3.1.4. Feedback Signaling + + Explicit notification mechanisms can be realized either by in-band + signaling (notifications piggybacked along with the data traffic) or + by out-of-band signaling [Sarola07]. The latter case requires + additional protocols and a secure binding between the signals and the + packets they refer to. Out-of-band signaling can be further + subdivided into path-coupled and path-decoupled approaches. + + Open questions concerning feedback signaling include: + + - At which protocol layer should the feedback signaling occur + (IP/network layer assisted, transport layer assisted, hybrid + solutions, shim layer, intermediate sub-layer, etc.)? Should the + feedback signaling be path-coupled or path-decoupled? + + - What is the optimal frequency of feedback (only in case of + congestion events, per RTT, per packet, etc.)? + + - What direction should feedback take (from network resource via + receiver to sender, or directly back to sender)? + +3.2. Challenge 2: Corruption Loss + + It is common for congestion control mechanisms to interpret packet + loss as a sign of congestion. This is appropriate when packets are + dropped in routers because of a queue that overflows, but there are + other possible reasons for packet drops. In particular, in wireless + networks, packets can be dropped because of corruption loss, + rendering the typical reaction of a congestion control mechanism + inappropriate. As a result, non-congestive loss may be more + prevalent in these networks due to corruption loss (when the wireless + link cannot be conditioned to properly control its error rate or due + to transient wireless link interruption in areas of poor coverage). + + TCP over wireless and satellite is a topic that has been investigated + for a long time [Krishnan04]. There are some proposals where the + congestion control mechanism would react as if a packet had not been + dropped in the presence of corruption (cf. TCP HACK [Balan01]), but + + + +Papadimitriou, et al. Informational [Page 17] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + discussions in the IETF have shown (see, for instance, the discussion + that occurred in April 2003 on the Datagram Congestion Control + Protocol (DCCP) working group list + http://www.ietf.org/mail-archive/web/dccp/current/mail6.html) that + there is no agreement that this type of reaction is appropriate. For + instance, it has been said that congestion can manifest itself as + corruption on shared wireless links, and it is questionable whether a + source that sends packets that are continuously impaired by link + noise should keep sending at a high rate because it has lost the + integrity of the feedback loop. + + Generally, two questions must be addressed when designing a + congestion control mechanism that takes corruption loss into account: + + 1. How is corruption detected? + + 2. What should be the reaction? + + In addition to question 1 above, it may be useful to consider + detecting the reason for corruption, but this has not yet been done + to the best of our knowledge. + + Corruption detection can be done using an in-band or out-of-band + signaling mechanism, much in the same way as described for + Challenge 1. Additionally, implicit detection can be considered: + link layers sometimes retransmit erroneous frames, which can cause + the end-to-end delay to increase -- but, from the perspective of a + sender at the transport layer, there are many other possible reasons + for such an effect. + + Header checksums provide another implicit detection possibility: if a + checksum only covers all the necessary header fields and this + checksum does not show an error, it is possible for errors to be + found in the payload using a second checksum. Such error detection + is possible with UDP-Lite and DCCP; it was found to work well over a + General Packet Radio Service (GPRS) network in a study [Chester04] + and poorly over a WiFi network in another study [Rossi06] [Welzl08]. + Note that while UDP-Lite and DCCP enable the detection of corruption, + the specifications of these protocols do not foresee any specific + reaction to it for the time being. + + + + + + + + + + + +Papadimitriou, et al. Informational [Page 18] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + The idea of having a transport endpoint detecting and accordingly + reacting (or not) to corruption poses a number of interesting + questions regarding cross-layer interactions. As IP is designed to + operate over arbitrary link layers, it is therefore difficult to + design a congestion control mechanism on top of it that appropriately + reacts to corruption -- especially as the specific data link layers + that are in use along an end-to-end path are typically unknown to + entities at the transport layer. + + While the IETF has not yet specified how a congestion control + mechanism should react to corruption, proposals exist in the + literature, e.g., [Tickoo05]. For instance, TCP Westwood [Mascolo01] + sets the congestion window equal to the measured bandwidth at the + time of congestion in response to three DupACKs or a timeout. This + measurement is obtained by counting and filtering the ACK rate. This + setting provides a significant goodput improvement in noisy channels + because the "blind" by half window reduction of standard TCP is + avoided, i.e., the window is not reduced by too much. + + Open questions concerning corruption loss include: + + - How should corruption loss be detected? + + - How should a source react when it is known that corruption has + occurred? + + - Can an ECN-capable flow infer that loss must be due to corruption + just from lack of explicit congestion notifications around a loss + episode [Tickoo05]? Or could this inference be dangerous, given + the transport does not know whether all queues on the path are + ECN-capable or not? + +3.3. Challenge 3: Packet Size + + TCP does not take packet size into account when responding to losses + or ECN. Over past years, the performance of TCP congestion avoidance + algorithms has been extensively studied. The well-known "square root + formula" provides an estimation of the performance of the TCP + congestion avoidance algorithm for TCP Reno [RFC2581]. [Padhye98] + enhances the model to account for timeouts, receiver window, and + delayed ACKs. + + For the sake of the present discussion, we will assume that the TCP + throughput is expressed using the simplified formula. Using this + formula, the TCP throughput B is proportional to the segment size and + inversely proportional to the RTT and the square root of the drop + probability: + + + + +Papadimitriou, et al. Informational [Page 19] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + S 1 + B ~ C --- ------- + RTT sqrt(p) + + where + + C is a constant + S is the TCP segment size (in bytes) + RTT is the end-to-end round-trip time of the TCP + connection (in seconds) + p is the packet drop probability + + Neglecting the fact that the TCP rate linearly depends on it, + choosing the ideal packet size is a tradeoff between high throughput + (the larger a packet, the smaller the relative header overhead) and + low packet latency (the smaller a packet, the shorter the time that + is needed until it is filled with data). Observing that TCP is not + optimal for applications with streaming media (since reliable + in-order delivery and congestion control can cause arbitrarily long + delays), this tradeoff has not usually been considered for TCP + applications. Therefore, the influence of the packet size on the + sending rate has not typically been seen as a significant issue, + given there are still few paths through the Internet that support + packets larger than the 1500 bytes common with Ethernet. + + The situation is already different for the Datagram Congestion + Control Protocol (DCCP) [RFC4340], which has been designed to enable + unreliable but congestion-controlled datagram transmission, avoiding + the arbitrary delays associated with TCP. DCCP is intended for + applications such as streaming media that can benefit from control + over the tradeoffs between delay and reliable in-order delivery. + + DCCP provides for a choice of modular congestion control mechanisms. + DCCP uses Congestion Control Identifiers (CCIDs) to specify the + congestion control mechanism. Three profiles are currently + specified: + + - DCCP Congestion Control ID 2 (CCID 2) [RFC4341]: TCP-like + Congestion Control. CCID 2 sends data using a close approximation + of TCP's congestion control as well as incorporating a variant of + Selective Acknowledgment (SACK) [RFC2018] [RFC3517]. CCID 2 is + suitable for senders that can adapt to the abrupt changes in the + congestion window typical of TCP's AIMD congestion control, and + particularly useful for senders that would like to take advantage + of the available bandwidth in an environment with rapidly changing + conditions. + + + + + +Papadimitriou, et al. Informational [Page 20] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + - DCCP Congestion Control ID 3 (CCID 3) [RFC4342]: TCP-Friendly Rate + Control (TFRC) [RFC5348] is a congestion control mechanism + designed for unicast flows operating in a best-effort Internet + environment. When competing for bandwidth, its window is similar + to TCP flows but has a much lower variation of throughput over + time than TCP, making it more suitable for applications such as + streaming media where a relatively smooth sending rate is of + importance. CCID 3 is appropriate for flows that would prefer to + minimize abrupt changes in the sending rate, including streaming + media applications with small or moderate receiver buffering + before playback. + + - DCCP Congestion Control ID 4 (CCID 4) [RFC5622]: TFRC Small + Packets (TFRC-SP) [RFC4828], a variant of the TFRC mechanism, has + been designed for applications that exchange small packets. The + objective of TFRC-SP is to achieve the same bandwidth in bits per + second as a TCP flow using packets of up to 1500 bytes. TFRC-SP + enforces a minimum interval of 10 ms between data packets to + prevent a single flow from sending small packets arbitrarily + frequently. CCID 4 has been designed to be used either by + applications that use a small fixed segment size, or by + applications that change their sending rate by varying the segment + size. Because CCID 4 is intended for applications that use a + fixed small segment size, or that vary their segment size in + response to congestion, the transmit rate derived from the TCP + throughput equation is reduced by a factor that accounts for the + packet header size, as specified in [RFC4828]. + + The resulting open questions are: + + - How does TFRC-SP operate under various network conditions? + + - How can congestion control be designed so as to scale with packet + size (dependency of congestion algorithm on packet size)? + + Today, many network resources are designed so that packet processing + cannot be overloaded even for incoming loads at the maximum bit rate + of the line. If packet processing can handle sustained load r + [packet per second] and the minimum packet size is h [bit] (i.e., + frame, packet, and transport headers with no payload), then a line + rate of x [bit per second] will never be able to overload packet + processing as long as x =< r*h. + + However, realistic equipment is often designed to only cope with a + near-worst-case workload with a few larger packets in the mix, rather + than the worst-case scenario of all minimum-size packets. In this + case, x = r*(h + e) for some small value of e. Therefore, packet + congestion is not impossible for runs of small packets (e.g., TCP + + + +Papadimitriou, et al. Informational [Page 21] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + ACKs or denial-of-service (DoS) attacks with TCP SYNs or small UDP + datagrams). But absent such anomalous workloads, equipment vendors + at the 2008 ICCRG meeting believed that equipment could still be + designed so that any congestion should be due to bit overload and not + packet overload. + + This observation raises additional open issues: + + - Can bit congestion remain prevalent? + + Being able to assume that congestion is generally due to excess + bits and not excess packets is a useful simplifying assumption in + the design of congestion control protocols. Can we rely on this + assumption for the future? An alternative view is that in-network + processing will become commonplace, so that per-packet processing + will as likely be the bottleneck as per-bit transmission [Shin08]. + + Over the last three decades, performance gains have mainly been + achieved through increased packet rates and not bigger packets. + But if bigger maximum segment sizes do become more prevalent, tiny + segments (e.g., ACKs) will not stop being widely used -- leading + to a widening range of packet sizes. + + The open question is thus whether or not packet processing rates + (r) will keep up with growth in transmission rates (x). A + superficial look at Moore's Law-type trends would suggest that + processing (r) will continue to outstrip growth in transmission + (x). But predictions based on actual knowledge of technology + futures would be useful. Another open question is whether there + are likely to be more small packets in the average packet mix. If + the answers to either of these questions predict that packet + congestion could become prevalent, congestion control protocols + will have to be more complicated. + + - Confusable causes of loss + + There is a considerable body of research on how to distinguish + whether packet drops are due to transmission corruption or to + congestion. But the full list of confusable causes of loss is + longer and includes transmission corruption loss, congestion loss + (bit congestion and packet congestion), and policing loss. + + If congestion is due to excess bits, the bit rate should be + reduced. If congestion is due to excess packets, the packet rate + can be reduced without reducing the bit rate -- by using larger + packets. However, if the transport cannot tell which of these + causes led to a specific packet drop, its only safe response is to + reduce the bit rate. This is why the Internet would be more + + + +Papadimitriou, et al. Informational [Page 22] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + complicated if packet congestion were prevalent, as reducing the + bit rate normally also reduces the packet rate, while reducing the + packet rate does not necessarily reduce the bit rate. + + Given distinguishing between corruption loss and congestion is + already an open issue (Section 3.2), if that problem is ever + solved, a further open issue would be whether to standardize a + solution that distinguishes all the above causes of loss, and not + just two of them. + + Nonetheless, even if we find a way for network equipment to + explicitly distinguish which sort of loss has occurred, we will + never be able to assume that such a smart AQM solution is deployed + at every congestible resource throughout the Internet -- at every + higher-layer device like firewalls, proxies, and servers; and at + every lower-layer device like low-end hubs, DSLAMs, Wireless LAN + (WLAN) cards, cellular base-stations, and so on. Thus, transport + protocols will always have to cope with packet drops due to + unpredictable causes, so we should always treat AQM as an + optimization, given it will never be ubiquitous throughout the + public Internet. + + - What does a congestion notification on a packet of a certain size + mean? + + The open issue here is whether a loss or explicit congestion mark + should be interpreted as a single congestion event irrespective of + the size of the packet lost or marked, or whether the strength of + the congestion notification is weighted by the size of the packet. + This issue is discussed at length in [Bri10], along with other + aspects of packet size and congestion control. + + [Bri10] makes the strong recommendation that network equipment + should drop or mark packets with a probability independent of each + specific packet's size, while congestion controls should respond + to dropped or marked packets in proportion to the packet's size. + + - Packet size and congestion control protocol design + + If the above recommendation is correct -- that the packet size of + a congestion notification should be taken into account when the + transport reads, and not when the network writes, the notification + -- it opens up a significant problem of protocol engineering and + re-engineering. Indeed, TCP does not take packet size into + account when responding to losses or ECN. At present, this is not + a pressing problem because use of 1500 byte data segments is very + prevalent for TCP, and the incidence of alternative maximum + + + + +Papadimitriou, et al. Informational [Page 23] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + segment sizes is not large. However, we should design the + Internet's protocols so they will scale with packet size. So, an + open issue is whether we should evolve TCP to be sensitive to + packet size, or expect new protocols to take over. + + As we continue to standardize new congestion control protocols, we + must then face the issue of how they should account for packet + size. It is still an open research issue to establish whether TCP + was correct in not taking packet size into account. If it is + determined that TCP was wrong in this respect, we should + discourage future protocol designs from following TCP's example. + For example, as explained above, the small-packet variant of TCP- + friendly rate control (TFRC-SP [RFC4828]) is an experimental + protocol that aims to take packet size into account. Whatever + packet size it uses, it ensures that its rate approximately equals + that of a TCP using 1500 byte segments. This raises the further + question of whether TCP with 1500 byte segments will be a suitable + long-term gold standard, or whether we need a more thorough review + of what it means for a congestion control mechanism to scale with + packet size. + +3.4. Challenge 4: Flow Startup + + The beginning of data transmissions imposes some further, unique + challenges: when a connection to a new destination is established, + the end-systems have hardly any information about the characteristics + of the path in between and the available bandwidth. In this flow + startup situation, there is no obvious choice as to how to start to + send. A similar problem also occurs after relatively long idle + times, since the congestion control state then no longer reflects + current information about the state of the network (flow restart + problem). + + Van Jacobson [Jacobson88] suggested using the slow-start mechanism + both for the flow startup and the flow restart, and this is today's + standard solution [RFC2581] [RFC5681]. Per [RFC5681], the slow-start + algorithm is used when the congestion window (cwnd) < slow-start + threshold (ssthresh), whose initial value is set arbitrarily high + (e.g., to the size of the largest possible advertised window) and + reduced in response to congestion. During slow-start, TCP increments + the cwnd by at most Sender Maximum Segment Size (MSS) bytes for each + ACK received that cumulatively acknowledges new data. Slow-start + ends when cwnd exceeds ssthresh or when congestion is observed. + However, the slow-start is not optimal in many situations. First, it + can take quite a long time until a sender can fully utilize the + available bandwidth on a path. Second, the exponential increase may + be too aggressive and cause multiple packet loss if large congestion + + + + +Papadimitriou, et al. Informational [Page 24] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + windows are reached (slow-start overshooting). Finally, the slow- + start does not ensure that new flows converge quickly to a reasonable + share of resources, particularly when the new flows compete with + long-lived flows and come out of slow-start early (slow-start vs + overshoot tradeoff). This convergence problem may even worsen if + more aggressive congestion control variants are widely used. + + The slow-start and its interaction with the congestion avoidance + phase was largely designed by intuition [Jacobson88]. So far, little + theory has been developed to understand the flow startup problem and + its implication on congestion control stability and fairness. There + is also no established methodology to evaluate whether new flow + startup mechanisms are appropriate or not. + + As a consequence, it is a non-trivial task to address the + shortcomings of the slow-start algorithm. Several experimental + enhancements have been proposed, such as congestion window validation + [RFC2861] and limited slow-start [RFC3742]. There are also ongoing + research activities, focusing, e.g., on bandwidth estimation + techniques, delay-based congestion control, or rate-pacing + mechanisms. However, any alternative end-to-end flow startup + approach has to cope with the inherent problem that there is no or + only little information about the path at the beginning of a data + transfer. This uncertainty could be reduced by more expressive + feedback signaling (cf. Section 3.1). For instance, a source could + learn the path characteristics faster with the Quick-Start mechanism + [RFC4782]. But even if the source knew exactly what rate it should + aim for, it would still not necessarily be safe to jump straight to + that rate. The end-system still does not know how a change in its + own rate will affect the path, which also might become congested in + less than one RTT. Further research would be useful to understand + the effect of decreasing the uncertainty by explicit feedback + separately from control theoretic stability questions. Furthermore, + flow startup also raises fairness questions. For instance, it is + unclear whether it could be reasonable to use a faster startup when + an end-system detects that a path is currently not congested. + + In summary, there are several topics for further research concerning + flow startup: + + - Better theoretical understanding of the design and evaluation of + flow startup mechanisms, concerning their impact on congestion + risk, stability, and fairness. + + - Evaluating whether it may be appropriate to allow alternative + starting schemes, e.g., to allow higher initial rates under + certain constraints [Chu10]; this also requires refining the + definition of fairness for startup situations. + + + +Papadimitriou, et al. Informational [Page 25] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + - Better theoretical models for the effects of decreasing + uncertainty by additional network feedback, particularly if the + path characteristics are very dynamic. + +3.5. Challenge 5: Multi-Domain Congestion Control + + Transport protocols such as TCP operate over the Internet, which is + divided into autonomous systems. These systems are characterized by + their heterogeneity as IP networks are realized by a multitude of + technologies. + +3.5.1. Multi-Domain Transport of Explicit Congestion Notification + + Different conditions and their variations lead to correlation effects + between policers that regulate traffic against certain conformance + criteria. + + With the advent of techniques allowing for early detection of + congestion, packet loss is no longer the sole metric of congestion. + ECN (Explicit Congestion Notification) marks packets -- set by active + queue management techniques -- to convey congestion information, + trying to prevent packet losses (packet loss and the number of + packets marked gives an indication of the level of congestion). + Using TCP ACKs to feed back that information allows the hosts to + realign their transmission rate and thus encourages them to + efficiently use the network. In IP, ECN uses the two least + significant bits of the (former) IPv4 Type of Service (TOS) octet or + the (former) IPv6 Traffic Class octet [RFC2474] [RFC3260]. Further, + ECN in TCP uses two bits in the TCP header that were previously + defined as reserved [RFC793]. + + ECN [RFC3168] is an example of a congestion feedback mechanism from + the network toward hosts. The congestion-based feedback scheme, + however, has limitations when applied on an inter-domain basis. + Indeed, Sections 8 and 19 of [RFC3168] detail the implications of two + possible attacks: + + 1. non-compliance: a network erasing a Congestion Experienced (CE) + codepoint introduced earlier on the path, and + + 2. subversion: a network changing Not ECN-Capable Transport (Not-ECT) + to ECT. + + Both of these problems could allow an attacking network to cause + excess congestion in an upstream network, even if the transports were + behaving correctly. There are to date two possible solutions to the + non-compliance problem (number 1 above): the ECN-nonce [RFC3540] and + the [CONEX] work item inspired by the re-ECN incentive system + + + +Papadimitriou, et al. Informational [Page 26] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + [Bri09]. Nevertheless, accidental rather than malicious erasure of + ECN is an issue for IPv6 where the absence of an IPv6 header checksum + implies that corruption of ECN could be more impacting than in the + IPv4 case. + + Fragmentation is another issue: the ECN-nonce cannot protect against + misbehaving receivers that conceal marked fragments; thus, some + protection is lost in situations where path MTU discovery is + disabled. Note also that ECN-nonce wouldn't protect against the + subversion issue (number 2 above) because, by definition, a Not-ECT + packet comes from a source without ECN enabled, and therefore without + the ECN-nonce enabled. So, there is still room for improvement on + the ECN mechanism when operating in multi-domain networks. + + Operational/deployment experience is nevertheless required to + determine the extent of these problems. The second problem is mainly + related to deployment and usage practices and does not seem to result + in any specific research challenge. + + Another controversial solution in a multi-domain environment may be + the TCP rate controller (TRC), a traffic conditioner that regulates + the TCP flow at the ingress node in each domain by controlling packet + drops and delays of the packets in a flow. The outgoing traffic from + a TRC-controlled domain is shaped in such a way that no packets are + dropped at the policer. However, the TRC interferes with the end-to- + end TCP model, and thus it would interfere with past and future + diversity of TCP implementations (violating the end-to-end + principle). In particular, the TRC embeds the flow rate equality + view of fairness in the network, and would prevent evolution to forms + of fairness based on congestion-volume (Section 2.3). + +3.5.2. Multi-Domain Exchange of Topology or Explicit Rate Information + + Security is a challenge for multi-domain exchange of explicit rate + signals, whether in-band or out-of-band. At domain boundaries, + authentication and authorization issues can arise whenever congestion + control information is exchanged. From this perspective, the + Internet does not so far have any security architecture for this + problem. + + The future evolution of Internet inter-domain operation has to show + whether more multi-domain information exchange can be effectively + realized. This is of particular importance for congestion control + schemes that make use of explicit per-datagram rate feedback (e.g., + RCP or XCP) or explicit rate feedback that uses in-band congestion + signaling (e.g., Quick-Start) or out-of-band signaling (e.g., + CADPC/PTP). Explicit signaling exchanges at the inter-domain level + that result in local domain triggers are currently absent from the + + + +Papadimitriou, et al. Informational [Page 27] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + Internet. From this perspective, security issues resulting from + limited trust between different administrative units result in policy + enforcement that exacerbates the difficulty encountered when explicit + feedback congestion control information is exchanged between domains. + Note that even though authentication mechanisms could be extended for + this purpose (by recognizing that explicit rate schemes such as RCP + or XCP have the same inter-domain security requirements and structure + as IntServ), they suffer from the same scalability problems as + identified in [RFC2208]. Indeed, in-band rate signaling or out-of- + band per-flow traffic specification signaling (like in the Resource + Reservation Protocol (RSVP)) results in similar scalability issues + (see Section 3.1). + + Also, many autonomous systems only exchange some limited amount of + information about their internal state (topology hiding principle), + even though having more precise information could be highly + beneficial for congestion control. Indeed, revealing the internal + network structure is highly sensitive in multi-domain network + operations and thus also a concern when it comes to the deployability + of congestion control schemes. For instance, a network-assisted + congestion control scheme with explicit signaling could reveal more + information about the internal network dimensioning than TCP does + today. + +3.5.3. Multi-Domain Pseudowires + + Extending pseudowires across multiple domains poses specific issues. + Pseudowires (PWs) [RFC3985] may carry non-TCP data flows (e.g., Time- + Division Multiplexing (TDM) traffic or Constant Bit Rate (CBR) ATM + traffic) over a multi-domain IP network. Structure-Agnostic TDM over + Packet (SAToP) [RFC4553], Circuit Emulation Service over Packet + Switched Network (CESoPSN) [RFC5086], and TDM over IP (TDMoIP) + [RFC5087] are not responsive to congestion control as discussed in + [RFC2914] (see also [RFC5033]). The same observation applies to ATM + circuit emulating services (CESs) interconnecting CBR equipment + (e.g., Private Branch Exchanges (PBX)) across a Packet Switched + Network (PSN). + + Moreover, it is not possible to simply reduce the flow rate of a TDM + PW or an ATM PW when facing packet loss. Providers can rate-control + corresponding incoming traffic, but they may not be able to detect + that PWs carry TDM or CBR ATM traffic (mechanisms for characterizing + the traffic's temporal properties may not necessarily be supported). + + + + + + + + +Papadimitriou, et al. Informational [Page 28] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + This can be illustrated with the following example. + + ........... ............ + . . . + S1 --- E1 --- . . + . | . . + . === E5 === E7 --- + . | . . | + S2 --- E2 --- . . | + . . . | | + ........... . | v + . ----- R ---> + ........... . | ^ + . . . | | + S3 --- E3 --- . . | + . | . . | + . === E6 === E8 --- + . | . . + S4 --- E4 --- . . + . . . + ........... ............ + + \---- P1 ---/ \---------- P2 ----- + + Sources S1, S2, S3, and S4 are originating TDM over IP traffic. P1 + provider edges E1, E2, E3, and E4 are rate-limiting such traffic. + The Service Level Agreement (SLA) of provider P1 with transit + provider P2 is such that the latter assumes a BE traffic pattern and + that the distribution shows the typical properties of common BE + traffic (elastic, non-real time, non-interactive). + + The problem arises for transit provider P2 because it is not able to + detect that IP packets are carrying constant-bit-rate service traffic + for which the only useful congestion control mechanism would rely on + implicit or explicit admission control, meaning self-blocking or + enforced blocking, respectively. + + Assuming P1 providers are rate-limiting BE traffic, a transit P2 + provider router R may be subject to serious congestion as all TDM PWs + cross the same router. TCP-friendly traffic (e.g., each flow within + another PW) would follow TCP's AIMD algorithm of reducing the sending + rate by half, in response to each packet drop. Nevertheless, the PWs + carrying TDM traffic could take all the available capacity while + other more TCP-friendly or generally congestion-responsive traffic + reduced itself to nothing. Note here that the situation may simply + occur because S4 suddenly turns on additional TDM channels. + + + + + +Papadimitriou, et al. Informational [Page 29] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + It is neither possible nor desirable to assume that edge routers will + soon have the ability to detect the responsiveness of the carried + traffic, but it is still important for transit providers to be able + to police a fair, robust, responsive, and efficient congestion + control technique in order to avoid impacting congestion-responsive + Internet traffic. However, we must not require only certain specific + responses to congestion to be embedded within the network, which + would harm evolvability. So designing the corresponding mechanisms + in the data and control planes still requires further investigation. + +3.6. Challenge 6: Precedence for Elastic Traffic + + Traffic initiated by so-called elastic applications adapts to the + available bandwidth using feedback about the state of the network. + + For elastic applications, the transport dynamically adjusts the data + traffic sending rate to different network conditions. Examples + encompass short-lived elastic traffic including HTTP and instant- + messaging traffic, as well as long file transfers with FTP and + applications targeted by [LEDBAT]. In brief, elastic data + applications can show extremely different requirements and traffic + characteristics. + + The idea to distinguish several classes of best-effort traffic types + is rather old, since it would be beneficial to address the relative + delay sensitivities of different elastic applications. The notion of + traffic precedence was already introduced in [RFC791], and it was + broadly defined as "An independent measure of the importance of this + datagram". For instance, low-precedence traffic should experience + lower average throughput than higher-precedence traffic. Several + questions arise here: What is the meaning of "relative"? What is the + role of the transport layer? + + The preferential treatment of higher-precedence traffic combined with + appropriate congestion control mechanisms is still an open issue that + may, depending on the proposed solution, impact both the host and the + network precedence awareness, and thereby congestion control. + [RFC2990] points out that the interactions between congestion control + and DiffServ [RFC2475] remained unaddressed until recently. + + Recently, a study and a potential solution have been proposed that + introduce Guaranteed TFRC (gTFRC) [Lochin06]. gTFRC is an adaptation + of TCP-Friendly Rate Control providing throughput guarantees for + unicast flows over the DiffServ/Assured Forwarding (AF) class. The + purpose of gTFRC is to distinguish the guaranteed part from the best- + effort part of the traffic resulting from AF conditioning. The + proposed congestion control has been specified and tested inside + DCCP/CCID 3 for DiffServ/AF networks [Lochin07] [Jourjon08]. + + + +Papadimitriou, et al. Informational [Page 30] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + Nevertheless, there is still work to be performed regarding lower- + precedence traffic -- data transfers that are useful, yet not + important enough to warrant significantly impairing other traffic. + Examples of applications that could make use of such traffic are web + caches and web browsers (e.g., for pre-fetching) as well as peer-to- + peer applications. There are proposals for achieving low precedence + on a pure end-to-end basis (e.g., TCP Low Priority (TCP-LP) + [Kuzmanovic03]), and there is a specification for achieving it via + router mechanisms [RFC3662]. It seems, however, that network-based + lower-precedence mechanisms are not yet a common service on the + Internet. Since early 2010, end-to-end mechanisms for lower + precedence, e.g., [Shal10], have become common -- at least when + competing with other traffic as part of its own queues (e.g., in a + home router). But it is less clear whether users will be willing to + make their background traffic yield to other people's foreground + traffic, unless the appropriate incentives are created. + + There is an issue over how to reconcile two divergent views of the + relation between traffic class precedence and congestion control. + One view considers that congestion signals (losses or explicit + notifications) in one traffic class are independent of those in + another. The other relates marking of the classes together within + the active queue management (AQM) mechanism [Gibbens02]. In the + independent case, using a higher-precedence class of traffic gives a + higher scheduling precedence and generally lower congestion level. + In the linked case, using a higher-precedence class of traffic still + gives higher scheduling precedence, but results in a higher level of + congestion. This higher congestion level reflects the extra + congestion higher-precedence traffic causes to both classes combined. + The linked case separates scheduling precedence from rate control. + The end-to-end congestion control algorithm can separately choose to + take a higher rate by responding less to the higher level of + congestion. This second approach could become prevalent if weighted + congestion controls were common. However, it is an open issue how + the two approaches might co-exist or how one might evolve into the + other. + +3.7. Challenge 7: Misbehaving Senders and Receivers + + In the current Internet architecture, congestion control depends on + parties acting against their own interests. It is not in a + receiver's interest to honestly return feedback about congestion on + the path, effectively requesting a slower transfer. It is not in the + sender's interest to reduce its rate in response to congestion if it + can rely on others to do so. Additionally, networks may have + strategic reasons to make other networks appear congested. + + + + + +Papadimitriou, et al. Informational [Page 31] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + Numerous strategies to improve congestion control have already been + identified. The IETF has particularly focused on misbehaving TCP + receivers that could confuse a compliant sender into assigning + excessive network and/or server resources to that receiver (e.g., + [Savage99], [RFC3540]). But, although such strategies are worryingly + powerful, they do not yet seem common (however, evidence of attack + prevalence is itself a research requirement). + + A growing proportion of Internet traffic comes from applications + designed not to use congestion control at all, or worse, applications + that add more forward error correction as they experience more + losses. Some believe the Internet was designed to allow such + freedom, so it can hardly be called misbehavior. But others consider + it misbehavior to abuse this freedom [RFC3714], given one person's + freedom can constrain the freedom of others (congestion represents + this conflict of interests). Indeed, leaving freedom unchecked might + result in congestion collapse in parts of the Internet. + Proportionately, large volumes of unresponsive voice traffic could + represent such a threat, particularly for countries with less + generous provisioning [RFC3714]. Also, Internet video on demand + services that transfer much greater data rates without congestion + control are becoming popular. In general, it is recommended that + such UDP applications use some form of congestion control [RFC5405]. + + Note that the problem is not just misbehavior driven by a self- + interested desire for more bandwidth. Indeed, congestion control may + be attacked by someone who makes no gain for themselves, other than + the satisfaction of harming others (see Security Considerations in + Section 4). + + Open research questions resulting from these considerations are: + + - By design, new congestion control protocols need to enable one end + to check the other for protocol compliance. How would such + mechanisms be designed? + + - Which congestion control primitives could safely satisfy more + demanding applications (smoother than TFRC, faster than high-speed + TCPs), so that application developers and users do not turn off + congestion control to get the rate they expect and need? + + Note also that self-restraint could disappear from the Internet. So, + it may no longer be sufficient to rely on developers/users + voluntarily submitting themselves to congestion control. As a + consequence, mechanisms to enforce fairness (see Sections 2.3, 3.4, + and 3.5) need to have more emphasis within the research agenda. + + + + + +Papadimitriou, et al. Informational [Page 32] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + +3.8. Other Challenges + + This section provides additional challenges and open research issues + that are not (at this point in time) deemed so significant, or they + are of a different nature compared to the main challenges depicted + so far. + +3.8.1. RTT Estimation + + Several congestion control schemes have to precisely know the round- + trip time (RTT) of a path. The RTT is a measure of the current delay + on a network. It is defined as the delay between the sending of a + packet and the reception of a corresponding response, if echoed back + immediately by the receiver upon receipt of the packet. This + corresponds to the sum of the one-way delay of the packet and the + (potentially different) one-way delay of the response. Furthermore, + any RTT measurement also includes some additional delay due to the + packet processing in both end-systems. + + There are various techniques to measure the RTT: active measurements + inject special probe packets into the network and then measure the + response time, using, e.g., ICMP. In contrast, passive measurements + determine the RTT from ongoing communication processes, without + sending additional packets. + + The connection endpoints of transport protocols such as TCP, the + Stream Control Transmission Protocol (SCTP), and DCCP, as well as + several application protocols, keep track of the RTT in order to + dynamically adjust protocol parameters such as the retransmission + timeout (RTO) or the rate-control equation. They can implicitly + measure the RTT on the sender side by observing the time difference + between the sending of data and the arrival of the corresponding + acknowledgments. For TCP, this is the default RTT measurement + procedure; it is used in combination with Karn's algorithm, which + prohibits RTT measurements from retransmitted segments [RFC2988]. + Traditionally, TCP implementations take one RTT measurement at a time + (i.e., about once per RTT). As an alternative, the TCP timestamp + option [RFC1323] allows more frequent explicit measurements, since a + sender can safely obtain an RTT sample from every received + acknowledgment. In principle, similar measurement mechanisms are + used by protocols other than TCP. + + Sometimes it would be beneficial to know the RTT not only at the + sender, but also at the receiver, e.g., to find the one-way variation + in delay due to one-way congestion. A passive receiver can deduce + some information about the RTT by analyzing the sequence numbers of + received segments. But this method is error-prone and only works if + the sender permanently sends data. Other network entities on the + + + +Papadimitriou, et al. Informational [Page 33] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + path can apply similar heuristics in order to approximate the RTT of + a connection, but this mechanism is protocol-specific and requires + per-connection state. In the current Internet, there is no simple + and safe solution to determine the RTT of a connection in network + entities other than the sender. The more fundamental question is to + determine whether it is necessary or not for network elements to + measure or know the RTT. + + As outlined earlier in this document, the round-trip time is + typically not a constant value. For a given path, there is a + theoretical minimum value, which is given by the minimum + transmission, processing, and propagation delay on that path. + However, additional variable delays might be caused by congestion, + cross-traffic, shared-media access control schemes, recovery + procedures, or other sub-IP layer mechanisms. Furthermore, a change + of the path (e.g., route flapping, hand-over in mobile networks) can + result in completely different delay characteristics. + + Due to this variability, one single measured RTT value is hardly + sufficient to characterize a path. This is why many protocols use + RTT estimators that derive an averaged value and keep track of a + certain history of previous samples. For instance, TCP endpoints + derive a smoothed round-trip time (SRTT) from an exponential weighted + moving average [RFC2988]. Such a low-pass filter ensures that + measurement noise and single outliers do not significantly affect the + estimated RTT. Still, a fundamental drawback of low-pass filters is + that the averaged value reacts more slowly to sudden changes in the + measured RTT. There are various solutions to overcome this effect: + For instance, the standard TCP retransmission timeout calculation + considers not only the SRTT, but also a measure for the variability + of the RTT measurements [RFC2988]. Since this algorithm is not well + suited for frequent RTT measurements with timestamps, certain + implementations modify the weight factors (e.g., [Sarola02]). There + are also proposals for more sophisticated estimators, such as Kalman + filters or estimators that utilize mainly peak values. + + However, open questions related to RTT estimation in the Internet + remain: + + - Optimal measurement frequency: Currently, there is no theory or + common understanding of the right time scale of RTT measurement. + In particular, the necessity for rather frequent measurements + (e.g., per packet) is not well understood. There is some + empirical evidence that such frequent sampling may not have a + significant benefit [Allman99]. + + + + + + +Papadimitriou, et al. Informational [Page 34] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + - Filter design: A closely related question is how to design good + filters for the measured samples. The existing algorithms are + known to be robust, but they are far from being perfect. The + fundamental problem is that there is no single set of RTT values + that could characterize the Internet as a whole, i.e., it is hard + to define a design target. + + - Default values: RTT estimators can fail in certain scenarios, + e.g., when any feedback is missing. In this case, default values + have to be used. Today, most default values are set to + conservative values that may not be optimal for most Internet + communication. Still, the impact of more aggressive settings is + not well understood. + + - Clock granularities: RTT estimation depends on the clock + granularities of the protocol stacks. Even though there is a + trend toward higher-precision timers, limited granularity + (particularly on low-cost devices) may still prevent highly + accurate RTT estimations. + +3.8.2. Malfunctioning Devices + + There is a long history of malfunctioning devices harming the + deployment of new and potentially beneficial functionality in the + Internet. Sometimes, such devices drop packets or even crash + completely when a certain mechanism is used, causing users to opt for + reliability instead of performance and disable the mechanism, or + operating-system vendors to disable it by default. One well-known + example is ECN, whose deployment was long hindered by malfunctioning + firewalls and is still hindered by malfunctioning home-hubs, but + there are many other examples (e.g., the Window Scaling option of + TCP) [Thaler07]. + + As new congestion control mechanisms are developed with the intention + of eventually seeing them deployed in the Internet, it would be + useful to collect information about failures caused by devices of + this sort, analyze the reasons for these failures, and determine + whether there are ways for such devices to do what they intend to do + without causing unintended failures. Recommendations for vendors of + these devices could be derived from such an analysis. It would also + be useful to see whether there are ways for failures caused by such + devices to become more visible to endpoints, or to the maintainers of + such devices. + + A possible way to reduce such problems in the future would be + guidelines for standards authors to ensure that "forward + compatibility" is considered in all IETF work. That is, the default + behavior of a device should be precisely defined for all possible + + + +Papadimitriou, et al. Informational [Page 35] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + values and combinations of protocol fields, and not just the minimum + necessary for the protocol being defined. Then, when previously + unused or reserved fields start to be used by newer devices to comply + with a new standard, older devices encountering unusual fields should + at least behave predictably. + +3.8.3. Dependence on RTT + + AIMD window algorithms that have the goal of packet conservation end + up converging on a rate that is inversely proportional to RTT. + However, control theoretic approaches to stability have shown that + only the increase in rate (acceleration), and not the target rate, + needs to be inversely proportional to RTT [Jin04]. + + It is possible to have more aggressive behaviors for some demanding + applications as long as they are part of a mix with less aggressive + transports [Key04]. This beneficial effect of transport type mixing + is probably how the Internet currently manages to remain stable even + in the presence of TCP slow-start, which is more aggressive than the + theory allows for stability. Research giving deeper insight into + these aspects would be very useful. + +3.8.4. Congestion Control in Multi-Layered Networks + + A network of IP nodes is just as vulnerable to congestion in the + lower layers between IP-capable nodes as it is to congestion on the + IP-capable nodes themselves. If network elements take a greater part + in congestion control (ECN, XCP, RCP, etc. -- see Section 3.1), these + techniques will either need to be deployed at lower layers as well, + or they will need to interwork with lower-layer mechanisms. + + [RFC5129] shows how to propagate ECN from lower layers upwards for + the specific case of MPLS, but to the authors' knowledge the layering + problem has not been addressed for explicit rate protocol proposals + such as XCP and RCP. Some issues are straightforward matters of + interoperability (e.g., how exactly to copy fields up the layers) + while others are less obvious (e.g., re-framing issues: if RCP were + deployed in a lower layer, how might multiple small RCP frames, all + with different rates in their headers, be assembled into a larger IP + layer datagram?). + + Multi-layer considerations also confound many mechanisms that aim to + discover whether every node on the path supports a new congestion + control protocol. For instance, some proposals maintain a secondary + Time to Live (TTL) field parallel to that in the IP header. Any + nodes that support the new behavior update both TTL fields, whereas + legacy IP nodes will only update the IP TTL field. This allows the + endpoints to check whether all IP nodes on the path support the new + + + +Papadimitriou, et al. Informational [Page 36] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + behavior, in which case both TTLs will be equal at the receiver. But + mechanisms like these overlook nodes at lower layers that might not + support the new behavior. + + A further related issue is congestion control across overlay networks + of relays [Hilt08] [Noel07] [Shen08]. + + Section 3.5.3 deals with inelastic multi-domain pseudowires (PWs), + where the identity of the pseudowire itself implies the + characteristics of the traffic crossing the multi-domain PSN + (independently of the actual characteristics of the traffic carried + in the PW). A more complex situation arises when inelastic traffic + is carried as part of a pseudowire (e.g., inelastic traffic over + Ethernet PW over PSN) whose edges do not have the means to + characterize the properties of the traffic encapsulated in the + Ethernet frames. In this case, the problem explained in + Section 3.5.3 is not limited to multi-domain pseudowires but more + generally arises from a "pseudowire carrying inelastic traffic" + (whether over a single- or multi-domain PSN). + + The problem becomes even more intricate when the Ethernet PW carries + both inelastic and elastic traffic. Addressing this issue further + supports our observation that a general framework to efficiently deal + with congestion control problems in multi-layer networks without + harming evolvability is absolutely necessary. + +3.8.5. Multipath End-to-End Congestion Control and Traffic Engineering + + Recent work has shown that multipath endpoint congestion control + [Kelly05] offers considerable benefits in terms of resilience and + resource usage efficiency. The IETF has since initiated a work item + on multipath TCP [MPTCP]. By pooling the resources on all paths, + even nodes not using multiple paths benefit from those that are. + + There is considerable further research to do in this area, + particularly to understand interactions with network-operator- + controlled route provisioning and traffic engineering, and indeed + whether multipath congestion control can perform better traffic + engineering than the network itself, given the right incentives + [Arkko09]. + +3.8.6. ALGs and Middleboxes + + An increasing number of application layer gateways (ALGs), + middleboxes, and proxies (see Section 3.6 of [RFC2775]) are deployed + at domain boundaries to verify conformance but also filter traffic + + + + + +Papadimitriou, et al. Informational [Page 37] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + and control flows. One motivation is to prevent information beyond + routing data leaking between autonomous systems. These systems split + up end-to-end TCP connections and disrupt end-to-end congestion + control. Furthermore, transport over encrypted tunnels may not allow + other network entities to participate in congestion control. + + Basically, such systems disrupt the primal and dual congestion + control components. In particular, end-to-end congestion control may + be replaced by flow-control backpressure mechanisms on the split + connections. A large variety of ALGs and middleboxes use such + mechanisms to improve the performance of applications (Performance + Enhancing Proxies, Application Accelerators, etc.). However, the + implications of such mechanisms, which are often proprietary and not + documented, have not been studied systematically so far. + + There are two levels of interference: + + - The "transparent" case, i.e., the endpoint address from the sender + perspective is still visible to the receiver (the destination IP + address). Relay systems that intercept payloads but do not relay + congestion control information provide an example. Such + middleboxes can prevent the operation of end-to-end congestion + control. + + - The "non-transparent" case, which causes fewer problems for + congestion control. Although these devices interfere with end-to- + end network transparency, they correctly terminate network, + transport, and application layer protocols on both sides, which + individually can be congestion controlled. + +4. Security Considerations + + Misbehavior may be driven by pure malice, or malice may in turn be + driven by wider selfish interests, e.g., using distributed denial-of- + service (DDoS) attacks to gain rewards by extortion [RFC4948]. DDoS + attacks are possible both because of vulnerabilities in operating + systems and because the Internet delivers packets without requiring + congestion control. + + To date, compliance with congestion control rules and being fair + require endpoints to cooperate. The possibility of uncooperative + behavior can be regarded as a security issue; its implications are + discussed throughout these documents in a scattered fashion. + + Currently the focus of the research agenda against denial of service + is about identifying attack-packets that attack machines and the + networks hosting them, with a particular focus on mitigating source + address spoofing. But if mechanisms to enforce congestion control + + + +Papadimitriou, et al. Informational [Page 38] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + fairness were robust to both selfishness and malice [Bri06], they + would also naturally mitigate denial of service against the network, + which can be considered (from the perspective of a well-behaved + Internet user) as a congestion control enforcement problem. Even + some denial-of-service attacks on hosts (rather than the network) + could be considered as a congestion control enforcement issue at the + higher layer. But clearly there are also denial-of-service attacks + that would not be solved by enforcing congestion control. + + Sections 3.5 and 3.7 on multi-domain issues and misbehaving senders + and receivers also discuss some information security issues suffered + by various congestion control approaches. + +5. References + +5.1. Informative References + + [Allman99] Allman, M. and V. Paxson, "On Estimating End-to-End + Network Path Properties", Proceedings of ACM SIGCOMM'99, + September 1999. + + [Andrew05] Andrew, L., Wydrowski, B., and S. Low, "An Example of + Instability in XCP", Manuscript available at + <http://netlab.caltech.edu/maxnet/XCP_instability.pdf>. + + [Arkko09] Arkko, J., Briscoe, B., Eggert, L., Feldmann, A., and M. + Handley, "Dagstuhl Perspectives Workshop on End-to-End + Protocols for the Future Internet," ACM SIGCOMM Computer + Communication Review, Vol. 39, No. 2, pp. 42-47, April + 2009. + + [Ath01] Athuraliya, S., Low, S., Li, V., and Q. Yin, "REM: Active + Queue Management", IEEE Network Magazine, Vol. 15, No. 3, + pp. 48-53, May 2001. + + [Balan01] Balan, R.K., Lee, B.P., Kumar, K.R.R., Jacob, L., Seah, + W.K.G., and A.L. Ananda, "TCP HACK: TCP Header Checksum + Option to Improve Performance over Lossy Links", + Proceedings of IEEE INFOCOM'01, Anchorage (Alaska), USA, + April 2001. + + [Bonald00] Bonald, T., May, M., and J.-C. Bolot, "Analytic + Evaluation of RED Performance", Proceedings of IEEE + INFOCOM'00, Tel Aviv, Israel, March 2000. + + + + + + + +Papadimitriou, et al. Informational [Page 39] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + [Bri06] Briscoe, B., "Using Self-interest to Prevent Malice; + Fixing the Denial of Service Flaw of the Internet", + Workshop on the Economics of Securing the Information + Infrastructure, October 2006, + <http://wesii.econinfosec.org/draft.php?paper_id=19>. + + [Bri07] Briscoe, B., "Flow Rate Fairness: Dismantling a + Religion", ACM SIGCOMM Computer Communication Review, + Vol. 37, No. 2, pp. 63-74, April 2007. + + [Bri08] Briscoe, B., Moncaster, T. and L. Burness, "Problem + Statement: Transport Protocols Don't Have To Do + Fairness", Work in Progress, July 2008. + + [Bri09] Briscoe, B., "Re-feedback: Freedom with Accountability + for Causing Congestion in a Connectionless Internetwork", + UCL PhD Thesis (2009). + + [Bri10] Briscoe, B. and J. Manner, "Byte and Packet Congestion + Notification," Work in Progress, October 2010. + + [Chester04] Chesterfield, J., Chakravorty, R., Banerjee, S., + Rodriguez, P., Pratt, I., and J. Crowcroft, "Transport + level optimisations for streaming media over wide-area + wireless networks", WIOPT'04, March 2004. + + [Chhabra02] Chhabra, P., Chuig, S., Goel, A., John, A., Kumar, A., + Saran, H., and R. Shorey, "XCHOKe: Malicious Source + Control for Congestion Avoidance at Internet Gateways," + Proceedings of IEEE International Conference on Network + Protocols (ICNP'02), Paris, France, November 2002. + + [Chiu89] Chiu, D.M. and R. Jain, "Analysis of the increase and + decrease algorithms for congestion avoidance in computer + networks", Computer Networks and ISDN Systems, Vol. 17, + pp. 1-14, 1989. + + [Clark88] Clark, D., "The design philosophy of the DARPA internet + protocols", ACM SIGCOMM Computer Communication Review, + Vol. 18, No. 4, pp. 106-114, August 1988. + + [Clark98] Clark, D. and W. Fang, "Explicit Allocation of Best- + Effort Packet Delivery Service", IEEE/ACM Transactions on + Networking, Vol. 6, No. 4, pp. 362-373, August 1998. + + [Chu10] Chu, J., Dukkipati, N., Cheng, Y., and M. Mathis, + "Increasing TCP's Initial Window", Work in Progress, + October 2010. + + + +Papadimitriou, et al. Informational [Page 40] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + [CONEX] IETF WG Action: Congestion Exposure (conex). + + [Dukki05] Dukkipati, N., Kobayashi, M., Zhang-Shen, R., and N. + McKeown, "Processor Sharing Flows in the Internet", + Proceedings of International Workshop on Quality of + Service (IWQoS'05), Passau, Germany, June 2005. + + [Dukki06] Dukkipati, N. and N. McKeown, "Why Flow-Completion Time + is the Right Metric for Congestion Control", ACM SIGCOMM + Computer Communication Review, Vol. 36, No. 1, January + 2006. + + [ECODE] "ECODE Project", European Commission Seventh Framework + Program, Grant No. 223936, <http://www.ecode-project.eu>. + + [Falk07] Falk, A., Pryadkin, Y., and D. Katabi, "Specification for + the Explicit Control Protocol (XCP)", Work in Progress, + January 2007. + + [Feldman04] + Feldman, M., Papadimitriou, C., Chuang, J., and I. + Stoica, "Free-Riding and Whitewashing in Peer-to-Peer + Systems" Proceedings of ACM SIGCOMM Workshop on Practice + and Theory of Incentives in Networked Systems (PINS'04) + 2004. + + [Firoiu00] Firoiu, V. and M. Borden, "A Study of Active Queue + Management for Congestion Control", Proceedings of IEEE + INFOCOM'00, Tel Aviv, Israel, March 2000. + + [Floyd93] Floyd, S. and V. Jacobson, "Random early detection + gateways for congestion avoidance", IEEE/ACM Transactions + on Networking, Vol. 1, No. 4, pp. 397-413, August 1993. + + [Floyd94] Floyd, S., "TCP and Explicit Congestion Notification", + ACM Computer Communication Review, Vol. 24, No. 5, + pp. 10-23, October 1994. + + [Gibbens02] Gibbens, R. and Kelly, F., "On Packet Marking at Priority + Queues", IEEE Transactions on Automatic Control, Vol. 47, + No. 6, pp. 1016-1020, 2002. + + [Ha08] Ha, S., Rhee, I., and L. Xu, "CUBIC: A new TCP-friendly + high-speed TCP variant", ACM SIGOPS Operating System + Review, Vol. 42, No. 5, pp. 64-74, 2008. + + + + + + +Papadimitriou, et al. Informational [Page 41] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + [Hilt08] Hilt, V. and I. Widjaja, "Controlling Overload in + Networks of SIP Servers", Proceedings of IEEE + International Conference on Network Protocols (ICNP'08), + Orlando (Florida), USA, October 2008. + + [Hollot01] Hollot, C., Misra, V., Towsley, D., and W.-B. Gong, "A + Control Theoretic Analysis of RED", Proceedings of IEEE + INFOCOM'01, Anchorage (Alaska), USA, April 2001. + + [Jacobson88] + Jacobson, V., "Congestion Avoidance and Control", + Proceedings of ACM SIGCOMM'88 Symposium, August 1988. + + [Jain88] Jain, R. and K. Ramakrishnan, "Congestion Avoidance in + Computer Networks with a Connectionless Network Layer: + Concepts, Goals, and Methodology", Proceedings of IEEE + Computer Networking Symposium, Washington DC, USA, April + 1988. + + [Jain90] Jain, R., "Congestion Control in Computer Networks: + Trends and Issues", IEEE Network, pp. 24-30, May 1990. + + [Jin04] Jin, Ch., Wei, D.X., and S. Low, "FAST TCP: Motivation, + Architecture, Algorithms, Performance", Proceedings of + IEEE INFOCOM'04, Hong-Kong, China, March 2004. + + [Jourjon08] Jourjon, G., Lochin, E., and P. Senac, "Design, + Implementation and Evaluation of a QoS-aware Transport + Protocol", Elsevier Computer Communications, Vol. 31, + No. 9, pp. 1713-1722, June 2008. + + [Katabi02] Katabi, D., M. Handley, and C. Rohrs, "Internet + Congestion Control for Future High Bandwidth-Delay + Product Environments", Proceedings of ACM SIGCOMM'02 + Symposium, August 2002. + + [Katabi04] Katabi, D., "XCP Performance in the Presence of Malicious + Flows", Proceedings of PFLDnet'04 Workshop, Argonne + (Illinois), USA, February 2004. + + [Kelly05] Kelly, F. and Th. Voice, "Stability of end-to-end + algorithms for joint routing and rate control", ACM + SIGCOMM Computer Communication Review, Vol. 35, No. 2, + pp. 5-12, April 2005. + + + + + + + +Papadimitriou, et al. Informational [Page 42] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + [Kelly98] Kelly, F., Maulloo, A., and D. Tan, "Rate control in + communication networks: shadow prices, proportional + fairness, and stability", Journal of the Operational + Research Society, Vol. 49, pp. 237-252, 1998. + + [Keshav07] Keshav, S., "What is congestion and what is congestion + control", Presentation at IRTF ICCRG Workshop, PFLDnet + 2007, Los Angeles (California), USA, February 2007. + + [Key04] Key, P., Massoulie, L., Bain, A., and F. Kelly, "Fair + Internet Traffic Integration: Network Flow Models and + Analysis", Annales des Telecommunications, Vol. 59, + No. 11-12, pp. 1338-1352, November-December 2004. + + [Krishnan04] + Krishnan, R., Sterbenz, J., Eddy, W., Partridge, C., and + M. Allman, "Explicit Transport Error Notification (ETEN) + for Error-Prone Wireless and Satellite Networks", + Computer Networks, Vol. 46, No. 3, October 2004. + + [Kuzmanovic03] + Kuzmanovic, A. and E.W. Knightly, "TCP-LP: A Distributed + Algorithm for Low Priority Data Transfer", Proceedings of + IEEE INFOCOM'03, San Francisco (California), USA, April + 2003. + + [LEDBAT] IETF WG Action: Low Extra Delay Background Transport + (ledbat). + + [Lochin06] Lochin, E., Dairaine, L., and G. Jourjon, "Guaranteed TCP + Friendly Rate Control (gTFRC) for DiffServ/AF Network", + Work in Progress, August 2006. + + [Lochin07] Lochin, E., Jourjon, G., and L. Dairaine, "Study and + enhancement of DCCP over DiffServ Assured Forwarding + class", 4th Conference on Universal Multiservice Networks + (ECUMN 2007), Toulouse, France, February 2007. + + [Low02] Low, S., Paganini, F., Wang, J., Adlakha, S., and J.C. + Doyle, "Dynamics of TCP/RED and a Scalable Control", + Proceedings of IEEE INFOCOM'02, New York (New Jersey), + 2002. + + [Low03.1] Low, S., "A duality model of TCP and queue management + algorithms", IEEE/ACM Transactions on Networking, + Vol. 11, No. 4, pp. 525-536, August 2003. + + + + + +Papadimitriou, et al. Informational [Page 43] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + [Low03.2] Low, S., Paganini, F., Wang, J., and J. Doyle, "Linear + stability of TCP/RED and a scalable control", Computer + Networks Journal, Vol. 43, No. 5, pp. 633-647, December + 2003. + + [Low05] Low, S., Andrew, L., and B. Wydrowski, "Understanding + XCP: equilibrium and fairness", Proceedings of IEEE + INFOCOM'05, Miami (Florida), USA, March 2005. + + [MacK95] MacKie-Mason, J. and H. Varian, "Pricing Congestible + Network Resources", IEEE Journal on Selected Areas in + Communications, Advances in the Fundamentals of + Networking, Vol. 13, No. 7, pp. 1141-1149, 1995. + + [Mascolo01] Mascolo, S., Casetti, Cl., Gerla M., Sanadidi, M.Y., and + R. Wang, "TCP Westwood: Bandwidth estimation for enhanced + transport over wireless links", Proceedings of MOBICOM + 2001, Rome, Italy, July 2001. + + [Moors02] Moors, T., "A critical review of "End-to-end arguments in + system design"", Proceedings of IEEE International + Conference on Communications (ICC) 2002, New York City + (New Jersey), USA, April/May 2002. + + [MPTCP] IETF WG Action: Multipath TCP (mptcp). + + [Noel07] Noel, E. and C. Johnson, "Initial Simulation Results That + Analyze SIP Based VoIP Networks Under Overload", + International Teletraffic Congress (ITC'07), Ottawa, + Canada, June 2007. + + [Padhye98] Padhye, J., Firoiu, V., Towsley, D., and J. Kurose, + "Modeling TCP Throughput: A Simple Model and Its + Empirical Validation", University of Massachusetts + (UMass), CMPSCI Tech. Report TR98-008, February 1998. + + [Pan00] Pan, R., Prabhakar, B., and K. Psounis, "CHOKe: a + stateless AQM scheme for approximating fair bandwidth + allocation", Proceedings of IEEE INFOCOM'00, Tel Aviv, + Israel, March 2000. + + [Pap02] Papadimitriou, I. and G. Mavromatis, "Stability of + Congestion Control Algorithms using Control Theory with + an application to XCP", Technical Report, 2002. + <http://www.stanford.edu/class/ee384y/projects/ + reports/ionnis.pdf>. + + + + + +Papadimitriou, et al. Informational [Page 44] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, + September 1981. + + [RFC793] Postel, J., "Transmission Control Protocol", STD 7, + RFC 793, September 1981. + + [RFC1323] Jacobson, V., Braden, R., and D. Borman, "TCP Extensions + for High Performance", RFC 1323, May 1992. + + [RFC1701] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic + Routing Encapsulation (GRE)", RFC 1701, October 1994. + + [RFC1958] Carpenter, B., Ed., "Architectural Principles of the + Internet", RFC 1958, June 1996. + + [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, + October 1996. + + [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP + Selective Acknowledgment Options", RFC 2018, October + 1996. + + [RFC2208] Mankin, A., Ed., Baker, F., Braden, B., Bradner, S., + O'Dell, M., Romanow, A., Weinrib, A., and L. Zhang, + "Resource ReSerVation Protocol (RSVP) -- Version 1 + Applicability Statement Some Guidelines on Deployment", + RFC 2208, September 1997. + + [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, + "Definition of the Differentiated Services Field (DS + Field) in the IPv4 and IPv6 Headers", RFC 2474, December + 1998. + + [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., + and W. Weiss, "An Architecture for Differentiated + Service", RFC 2475, December 1998. + + [RFC2581] Allman, M., Paxson, V., and W. Stevens, "TCP Congestion + Control", RFC 2581, April 1999. + + [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, + W., and G. Zorn, "Point-to-Point Tunneling Protocol + (PPTP)", RFC 2637, July 1999. + + [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, + G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", + RFC 2661, August 1999. + + + + +Papadimitriou, et al. Informational [Page 45] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, + February 2000. + + [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. + Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, + March 2000. + + [RFC2861] Handley, M., Padhye, J., and S. Floyd, "TCP Congestion + Window Validation", RFC 2861, June 2000. + + [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, + RFC 2914, September 2000. + + [RFC2988] Paxson, V. and M. Allman, "Computing TCP's Retransmission + Timer", RFC 2988, November 2000. + + [RFC2990] Huston, G., "Next Steps for the IP QoS Architecture", + RFC 2990, November 2000. + + [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol + Label Switching Architecture", RFC 3031, January 2001. + + [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., + Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack + Encoding", RFC 3032, January 2001. + + [RFC3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition + of Explicit Congestion Notification (ECN) to IP", + RFC 3168, September 2001. + + [RFC3260] Grossman, D., "New Terminology and Clarifications for + Diffserv", RFC 3260, April 2002. + + [RFC3517] Blanton, E., Allman, M., Fall, K., and L. Wang, "A + Conservative Selective Acknowledgment (SACK)-based Loss + Recovery Algorithm for TCP", RFC 3517, April 2003. + + [RFC3540] Spring, N., Wetherall, D., and D. Ely, "Robust Explicit + Congestion Notification (ECN) Signaling with Nonces", + RFC 3540, June 2003. + + [RFC3662] Bless, R., Nichols, K., and K. Wehrle, "A Lower Effort + Per-Domain Behavior (PDB) for Differentiated Services", + RFC 3662, December 2003. + + [RFC3714] Floyd, S., Ed., and J. Kempf, Ed., "IAB Concerns + Regarding Congestion Control for Voice Traffic in the + Internet", RFC 3714, March 2004. + + + +Papadimitriou, et al. Informational [Page 46] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + [RFC3742] Floyd, S., "Limited Slow-Start for TCP with Large + Congestion Windows", RFC 3742, March 2004. + + [RFC3985] Bryant, S., Ed., and P. Pate, Ed., "Pseudo Wire Emulation + Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. + + [RFC4301] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram + Congestion Control Protocol (DCCP)", RFC 4340, March + 2006. + + [RFC4341] Floyd, S. and E. Kohler, "Profile for Datagram Congestion + Control Protocol (DCCP) Congestion Control ID 2: TCP-like + Congestion Control", RFC 4341, March 2006. + + [RFC4342] Floyd, S., Kohler, E., and J. Padhye, "Profile for + Datagram Congestion Control Protocol (DCCP) Congestion + Control ID 3: TCP-Friendly Rate Control (TFRC)", + RFC 4342, March 2006. + + [RFC4553] Vainshtein, A., Ed., and YJ. Stein, Ed., "Structure- + Agnostic Time Division Multiplexing (TDM) over Packet + (SAToP)", RFC 4553, June 2006. + + [RFC4614] Duke, M., Braden, R., Eddy, W., and E. Blanton, "A + Roadmap for Transmission Control Protocol (TCP) + Specification Documents", RFC 4614, September 2006. + + [RFC4782] Floyd, S., Allman, M., Jain, A., and P. Sarolahti, + "Quick-Start for TCP and IP", RFC 4782, January 2007. + + [RFC4828] Floyd, S. and E. Kohler, "TCP Friendly Rate Control + (TFRC): The Small-Packet (SP) Variant", RFC 4828, April + 2007. + + [RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the + IAB workshop on Unwanted Traffic March 9-10, 2006", + RFC 4948, August 2007. + + [RFC5033] Floyd, S. and M. Allman, "Specifying New Congestion + Control Algorithms", BCP 133, RFC 5033, August 2007. + + [RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and + P. Pate, "Structure-Aware Time Division Multiplexed (TDM) + Circuit Emulation Service over Packet Switched Network + (CESoPSN)", RFC 5086, December 2007. + + + +Papadimitriou, et al. Informational [Page 47] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + [RFC5087] Stein, Y(J)., Shashoua, R., Insler, R., and M. Anavi, + "Time Division Multiplexing over IP (TDMoIP)", RFC 5087, + December 2007. + + [RFC5129] Davie, B., Briscoe, B., and J. Tay, "Explicit Congestion + Marking in MPLS", RFC 5129, January 2008. + + [RFC5290] Floyd, S. and M. Allman, "Comments on the Usefulness of + Simple Best-Effort Traffic", RFC 5290, July 2008. + + [RFC5348] Floyd, S., Handley, M., Padhye, J., and J. Widmer, "TCP + Friendly Rate Control (TFRC): Protocol Specification", + RFC 5348, September 2008. + + [RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage + Guidelines for Application Designers", BCP 145, RFC 5405, + November 2008. + + [RFC5622] Floyd, S. and E. Kohler, "Profile for Datagram Congestion + Control Protocol (DCCP) Congestion ID 4: TCP-Friendly + Rate Control for Small Packets (TFRC-SP)", RFC 5622, + August 2009. + + [RFC5681] Allman, M., Paxson, V., and E. Blanton, "TCP Congestion + Control", RFC 5681 (Obsoletes RFC 2581), September 2009. + + [RFC5783] Welzl, M. and W. Eddy, "Congestion Control in the RFC + Series", RFC 5783, February 2010. + + [RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion + Notification", RFC 6040, November 2010. + + [Rossi06] Rossi, M., "Evaluating TCP with Corruption Notification + in an IEEE 802.11 Wireless LAN", Master Thesis, + University of Innsbruck, November 2006. Available from + http://heim.ifi.uio.no/michawe/research/projects/ + corruption/. + + [Saltzer84] Saltzer, J., Reed, D., and D. Clark, "End-to-end + arguments in system design", ACM Transactions on Computer + Systems, Vol. 2, No. 4, November 1984. + + [Sarola02] Sarolahti, P. and A. Kuznetsov, "Congestion Control in + Linux TCP", Proceedings of the USENIX Annual Technical + Conference, 2002. + + + + + + +Papadimitriou, et al. Informational [Page 48] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + [Sarola07] Sarolahti, P., Floyd, S., and M. Kojo, "Transport-layer + Considerations for Explicit Cross-layer Indications", + Work in Progress, March 2007. + + [Savage99] Savage, S., Cardwell, N., Wetherall, D., and T. + Anderson, "TCP Congestion Control with a Misbehaving + Receiver", ACM SIGCOMM Computer Communication Review, + 1999. + + [Shal10] Shalunov, S., Hazel, G., and J. Iyengar, "Low Extra Delay + Background Transport (LEDBAT)", Work in Progress, October + 2010. + + [Shen08] Shen, C., Schulzrinne, H., and E. Nahum, "Session + Initiation Protocol (SIP) Server Overload Control: Design + and Evaluation, Principles", Systems and Applications of + IP Telecommunications (IPTComm'08), Heidelberg, Germany, + July 2008. + + [Shin08] Shin, M., Chong, S., and I. Rhee, "Dual-Resource TCP/AQM + for Processing-Constrained Networks", IEEE/ACM + Transactions on Networking, Vol. 16, No. 2, pp. 435-449, + April 2008. + + [Thaler07] Thaler, D., Sridharan, M., and D. Bansal, "Implementation + Report on Experiences with Various TCP RFCs", + Presentation to the IETF Transport Area, March 2007. + <http://www.ietf.org/proceedings/07mar/ + slides/tsvarea-3/>. + + [Tickoo05] Tickoo, O., Subramanian, V., Kalyanaraman, S., and K.K. + Ramakrishnan, "LT-TCP: End-to-End Framework to Improve + TCP Performance over Networks with Lossy Channels", + Proceedings of International Workshop on QoS (IWQoS), + Passau, Germany, June 2005. + + [TRILOGY] "Trilogy Project", European Commission Seventh Framework + Program (FP7), Grant No: 216372, <http://www.trilogy- + project.org>. + + [Vinnic02] Vinnicombe, G., "On the stability of networks operating + TCP-like congestion control," Proceedings of IFAC World + Congress, Barcelona, Spain, 2002. + + [Welzl03] Welzl, M., "Scalable Performance Signalling and + Congestion Avoidance", Springer (ISBN 1-4020-7570-7), + September 2003. + + + + +Papadimitriou, et al. Informational [Page 49] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + + [Welzl08] Welzl, M., Rossi, M., Fumagalli, A., and M. Tacca, + "TCP/IP over IEEE 802.11b WLAN: the Challenge of + Harnessing Known-Corrupt Data", Proceedings of IEEE + International Conference on Communications (ICC) 2008, + Beijing, China, May 2008. + + [Xia05] Xia, Y., Subramanian, L., Stoica, I., and S. + Kalyanaraman, "One more bit is enough", ACM SIGCOMM + Computer Communication Review, Vol. 35, No. 4, pp. 37-48, + 2005. + + [Zhang03] Zhang, H., Towsley, D., Hollot, C., and V. Misra, "A + Self-Tuning Structure for Adaptation in TCP/AQM + Networks", Proceedings of ACM SIGMETRICS'03 Conference, + San Diego (California), USA, June 2003. + +6. Acknowledgments + + The authors would like to thank the following people whose feedback + and comments contributed to this document: Keith Moore, Jan + Vandenabeele, and Larry Dunn (his comments at the Manchester ICCRG + and discussions with him helped with the section on packet- + congestibility). + + Dimitri Papadimitriou's contribution was partly funded by [ECODE], a + Seventh Framework Program (FP7) research project sponsored by the + European Commission. + + Bob Briscoe's contribution was partly funded by [TRILOGY], a research + project supported by the European Commission. + + Michael Scharf is now with Alcatel-Lucent. + +7. Contributors + + The following additional people have contributed to this document: + + - Wesley Eddy <weddy@grc.nasa.gov> + + - Bela Berde <bela.berde@gmx.de> + + - Paulo Loureiro <loureiro.pjg@gmail.com> + + - Chris Christou <christou_chris@bah.com> + + + + + + + +Papadimitriou, et al. Informational [Page 50] + +RFC 6077 Open Issues in Internet Congestion Control February 2011 + + +Authors' Addresses + + Dimitri Papadimitriou (editor) + Alcatel-Lucent + Copernicuslaan, 50 + 2018 Antwerpen, Belgium + + Phone: +32 3 240 8491 + EMail: dimitri.papadimitriou@alcatel-lucent.com + + + Michael Welzl + University of Oslo, Department of Informatics + PO Box 1080 Blindern + N-0316 Oslo, Norway + + EMail: michawe@ifi.uio.no + + + Michael Scharf + University of Stuttgart + Pfaffenwaldring 47 + 70569 Stuttgart, Germany + + EMail: michael.scharf@googlemail.com + + + Bob Briscoe + BT & UCL + B54/77, Adastral Park + Martlesham Heath + Ipswich IP5 3RE, UK + + EMail: bob.briscoe@bt.com + + + + + + + + + + + + + + + + + +Papadimitriou, et al. Informational [Page 51] + |