Congestion Control Principles Floyd, S., RFC 2914: Congestion Control Principles. , 2000
description
Transcript of Congestion Control Principles Floyd, S., RFC 2914: Congestion Control Principles. , 2000
Congestion Control PrinciplesFloyd, S., RFC 2914: Congestion Control Principles., 2000
Multimedia Communications LAB at HUFS Hongbeom Ahn ([email protected])
Sub Title
Page 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 Inter-
net The role of the standards process Forms of end-to-end congestion control TCP-specific issues
Page 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 conges-tion control
To discuss the role of the IETF in standardizing new conges-tion control
Page 4
Current standards on E2E congestion con-trol 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 conges-tion control or quality-of-service: Explicit Congestion Notification (ECN)
ECN allows end-to-end notification of network congestion without dropping pack-ets
Diff-Serv
Page 5
The Development of E2E Congestion Con-trol Preventing Congestion Collapse Fairness Used by flows for their own purposes
To maximize throughput To minimize delay and packet drops
Page 6
A Description of Congestion Collapse Congestion Collapse
Occurs when an increase in the network load results in a decrease in the use-ful 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 be-
fore reaching their dest.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 160
20
40
60
80
100
120
140
UDP Arrival RateUDP GoodputTCP GoodputTotal Goodput
Page 7
C/C for the Prevention of Congestion Col-lapse 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
Page 8
TCP Behavior(AIMD) AIMD
Rate increases by a fixed amount, Rate decreases by ½ cwnd to recover
Page 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
Page 10
C/C for Fairness (2)
Terminology from RFC 2309
TCP –compatible flowIn steady-state, uses no more bandwidth than a conformant TCP under similar condi-tions(drop-rate, RTT, MTU, etc)
Unresponsive flowDose 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
Page 11
C/C used by a flow for its own reasons
In an environment with per-flow scheduling or with small levels of sta-tistical 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
Page 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.
Page 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 pres-
ence 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...
Page 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 pack-
ets in the pipe.
Page 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 ag-
gressive.
Fast retransmit, fast recovery Subject to standardization:
Proposals for retransmitting packets based on one or two duplicate acknowledge-ments.
Does not require standardization?: Proposals for sending a new packet based on one or two duplicate acknowledge-
ments.