Roadmaps for congestion control for best-effort traffic: Tue May 14 08:44:21 PDT 2002 This is a quick overview of the current state of congestion control mechanisms in the Internet, including descriptions of some mechanisms in various stages of research, standardization, or deployment that seem likely to appear within the next few years as part of the congestion control mechanisms for best-effort traffic in the Internet. Thus, this can be seen as a rough description of the path that we believe congestion control for best-effort traffic is likely to take, if left to its current path of the incremental development and increment deployment of congestion control mechanisms. Congestion indications: * We have packet drops and ECN marks (in progress) as congestion indications. For best-effort traffic, the semantics of ECN are defined: a marked packet is functionally equivalent to a dropped packet, in terms of the response of end-to-end congestion control. Separate diffserv classes could have alternate semantics for the ECN bit. Transport protocols: * We have TCP and SCTP for unicast, reliable transport. * DCCP is in progress as a transport protocol for unicast, unreliable transfer. DCCP is being specified to be used with either TCP-like or TFRC congestion control. * Research on multicast transport protocols is in progress. * There have been proposals for alternate best-effort services, such as "scavenger" transport protocols that only used left-over bandwidth, or for two different best-effort classes optimizing for either high bandwidth or for low delay. Recent changes or changes in progress for TCP or to other transport protocols include the following: * Currently the TCP initial window is allowed to be two packets; soon an initial window of up to four packets should be Proposed Standard. * Research is in progress for mechanisms to make TCP more robust for reordered packets and for paths with unpredictable delays (e.g., delays that lead to spurious retransmit timeouts), and this could reach the deployment stage over the next few years. These mechanisms would easily carry over to other transport protocols. * Support for the ECN nonce, now undergoing standardization, would make the ECN congestion indication robust against errors in routers or against misbehaving TCP receivers. * The Congestion Manager would allow congestion state to be shared among multiple flows with the same source and destination address. It is hard to judge the likely deployment scenario for CM. * Preliminary research on modifying TCP's response function would make it more realistic for TCP to sustain congestion windows of thousands or tens of thousands of packets, for paths with available bandwidth. * There is a very speculative suggestion for an IP option, to be carried in TCP SYN packets and modified by routers, that would enable TCPs to start with larger initial windows, if approved by all of the routers along the path. This is one of the things that could be developed and evaluated on the incremental-deployment path. Routers: * Many routers have some form of Active Queue Management (generally RED), and there are beginning to be some routers with support for ECN. There is active research on new proposals for queue management mechanisms. There is no need for standardization in this area, as there is no need for all routers to use the same active queue management algorithms. (As an aside, ARED, Adaptive RED, only has one parameter that needs to be set, and that is the target average queue size in seconds.) * If different diffserv classes require separate semantics for the ECN bits, this would require support at the routers. (Classes using different diffserv code points could be used for alternate forms of "best-effort" traffic.) * The default scheduling mechanism for best-effort traffic is FIFO, but there has been a long history of calls (and dissentors) concerning the use of per-flow scheduling (e.g., Fair Queueing) for best-effort traffic. * With FIFO scheduling in particular, there is a need for mechanisms in routers to protect against misbehaving flows. With either FIFO or per-flow scheduling, there is a need for mechanisms to give concrete incentives to flows to use end-to-end congestion control. There has been research in this area, but it is hard to evaluate what the deployment path is likely to be. * With either FIFO or per-flow scheduling, it has been suggested that there is a need for some form of aggregate-based congestion control, for protection against crowds during flash crowds or Denial of Service attacks. Unmet needs for best-effort traffic: * Starting up faster than slow-start? * Making prompt use of newly-available bandwidth? * Quick recovery after a period of link outage (e.g., for a wireless link)? * Congestion control for flows that change their packet size, but not their sending rate in packets per second. * Fairness? * Making the most efficient use of the available bandwidth? * Distinguishing between congestion and corruption. * Preventing unnecessary packet drops on slow-start in environments with small-scale statistical multiplexing? (In environments with large-scale statistical multiplexing, the combination of AQM and ECN seems likely to be sufficient in this regard.) Open questions: * How important is it to add aggregate-based congestion control mechanisms to control traffic from flash crowds and DDoS attacks. * When is the bottleneck in the network likely to be in processing capacity in packets per second, and when is it likely to be capacity in bytes per second? How does the transport protocol infer which one is going on? Things judged (by me) not likely to happen in the normal evolutionary process in the short or medium term, for best-effort traffic: * Congestion-based pricing; * ECN++, with additional information being returned with the ECN information. * Additional per-packet feedback from routers.