1 / 15

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

Sub Title. Congestion Control Principles Floyd, S., RFC 2914: Congestion Control Principles. , 2000. Multimedia Communications LAB at HUFS Hongbeom Ahn (mythopoeic@paran.com). Index. Look at the Purpose of this RFC Current standards on end-to-end congestion control

yanka
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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.

More Related