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

Multimedia Communications LAB at HUFS Hongbeom Ahn (mythopoeic@paran.com)

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.