Congestion Control Principles Floyd, S., RFC 2914: Congestion Control Principles. , 2000

1. Sub Title Congestion Control PrinciplesFloyd, S., RFC 2914: Congestion Control Principles., 2000 Multimedia Communications LAB at HUFS HongbeomAhn(mythopoeic@paran.com)

2. Index • Look at the Purpose of this RFC • Current standards on end-to-end congestion control • The development of end-to-end congestion control in the Internet • The role of the standards process • Forms of end-to-end congestion control • TCP-specific issues

3. The “Goal” of this RFC • The Goal of this RFC • To explain the need for congestion control in the Internet • To discuss what constitute correct congestion control • To illustrate the dangers of neglecting to apply proper congestion control • To discuss the role of the IETF in standardizing new congestion control

4. Current standards on E2E congestion control • Back in the Time, 2000 • Standards on specific Transport Protocols • E.g TCP [RFC 2581] • Requirements on new Transport Protocols • E.g Reliable multicast protocols [RFC 2357] • Standards on communication between end-nodes and routers about congestion control or quality-of-service: • Explicit Congestion Notification (ECN) • ECN allows end-to-end notification of network congestion without dropping packets • Diff-Serv

5. The Development of E2E Congestion Control • Preventing Congestion Collapse • Fairness • Used by flows for their own purposes • To maximize throughput • To minimize delay and packet drops

6. A Description of Congestion Collapse • Congestion Collapse • Occurs when an increase in the network load results in a decrease in the useful work • When a packet loss occurred, -> the end points sent extra packets that repeated the information lost-> doubling the data rate sent • This pushed the entire network into a 'congestion collapse' where most packets were lost and the resultant throughput was negligible • Due to undelivered packets • When BW is wasted by delivering packets through the network that are dropped before reaching their dest.

7. C/C for the Prevention of Congestion Collapse • TCP in the early 80’s • TCP flow control to avoid overflowing receiver’s buffer • TCP’s Go-Back-N retransmission • FIFO scheduling, drop-tail queue management • A series of congestion collapse starting in 1986 • Modern TCP retransmit timer and congestion control • Packet drops as indications of congestion • AIMD(Additive Increase Multiplicative Decrease), Slow-Start • Exponential backoff of the retransmit timer • Not fixed RTO -> it is going to decrease the performance of TCP

8. TCP Behavior(AIMD) • AIMD • Rate increases by a fixed amount, Rate decreases by ½ cwnd to recover

9. C/C for Fairness (1) • For flows competing in a FIFO queue • Compatible E2E congestion control mechanisms are required for some degree of fairness • Potential concerns about fairness • Increasingly-aggressive, non-conformant TCP implementations (Poor-Quality) • A spiral of increasingly-aggressive transport protocols • A spiral of increasingly-aggressive web browsers • Best-effort traffic without E2E congestion control • Generating the new style of congestion control

10. C/C for Fairness (2) • Terminology from RFC 2309 • TCP –compatible flow In steady-state, uses no more bandwidth than a conformant TCP under similar conditions (drop-rate, RTT, MTU, etc) • Unresponsive flow Dose not slow down in response to congestion • Responsive but not TCP-compatible (Big Problems) Responsive to congestion, but does not compete equally with TCP in a queue with FIFO scheduling

11. C/C used by a flow for its own reasons • In an environment with per-flow scheduling or with small levels of statistical multiplexing • A flow’s delay and packet drop rate is in part a function of its own sending rate • In an environment with high levels of statistical multiplexing • Tragedy of the commons is avoided because the “players” are not individuals but software vendors • A flow’s delay and packet drop rate is a function of the E2E congestion control provided by software vendors for all users

12. A discussion of the role of the standards process • Standardization of transport protocols, QoS mechanisms, ECN • Aspects traditionally subject to standardization: • Issues related to interoperability. • Mechanisms deemed critical to performance: [For standardized transport protocols, that is.] • Basic congestion control mechanisms; • Fairness with respect to other best-effort traffic; • Traditionally not subject to standardization: • Implementation-specific issues. • Issues that do not affect interoperability,and do not significantly interfere with performance.

13. Forms of end-to-end congestion control • Issue 1: Avoiding congestion collapse from undelivered packets. • Solution: Congestion control to avoid a persistent high sending rate in presence of a high packet drop rate. • Issue 2: Fairness with competing TCP traffic in a queue with FIFO scheduling? • Solution: TCP-compatible congestion control, such as: • AIMD with compatible increase/decrease parameters; • equation-based congestion control with a compatible equation; • Layered multicast, receivers subscribing to layered multicast groups; • other forms...

14. TCP-specific issues (1) • Slow-start • Subject to standardization: Initial window. • Does not require standardization?: • Rate-based pacing • Exiting slow-start early • AIMD • Subject to standardization: • Increase/decrease constants; • Congestion control for return ACK path; • Window Increase based on byte-counting or ack-counting? • Does not require standardization?: • Interpretation of congestion window as sliding window, or limit to outstanding packets in the pipe.

15. TCP-specific issues (2) • Retransmit timers • Subject to standardization: • A proposal for more aggressive retransmit timers. • Does not require standardization?: • Modified mechanisms for setting retransmit timers that are not significantly more aggressive. • Fast retransmit, fast recovery • Subject to standardization: • Proposals for retransmitting packets based on one or two duplicate acknowledgements. • Does not require standardization?: • Proposals for sending a new packet based on one or two duplicate acknowledgements.