Promoting the Use of End-to-End Congestion Control in the Internet

Sally Floyd and Kevin Fall

Presented by Scott McLaren

Overview

Introduction The problem of unresponsive flows Identifying flows to regulate Alternate approaches Conclusions and future work

Introduction

End-to-end congestion control mechanisms of TCP are critical to the robustness of the Internet

We can no longer rely on all end-nodes to use congestion control for best-effort traffic

We also cannot rely on all developers to use congestion control

The network must participate in resource utilization (congestion control)

Approach 1 – Packet scheduling in routers to isolate flows Per-flow scheduling to regulate bandwidth Attempt max-min fairness

Approach 2 – Incentives for use of congestion control Restrict bandwidth of best-effort flows using a

large share of the bandwidth Incentive for users, developers, and protocol

designers Restrict bandwidth of flows without congestion

control

Approach 3 – financial incentives or pricing mechanisms Can network providers deploy effective

pricing structures fast enough to keep up with growth of best-effort traffic?

Definitions

Best-effort – UDP, etc. Unresponsive flows – flows that do not use end-to-

end congestion control and that do not reduce their load on the network when subjected to packet drops

TCP-friendly – a flow whose arrival rate does not exceed the arrival of a conformant TCP connection in the same circumstances

Goodput – the bandwidth delivered to the receiver, excluding duplicate packets

Congestion collapse – when an increase in the network load results in a decrease in the useful work done by the network

Unfairness

TCP flows competing with unresponsive UDP flows for scarce bandwidth

TCP flow reduces load, UDP uses the extra bandwidth

Due to TCP’s congestion control algorithms, throughput = 1/(roundtrip time)

With multiple congested gateways,

throughput = 1/sqrt(# congested gateways)

Simulations

3 TCP flows,1 UDP flow, FCFS Scheduling

3 TCP flows,1 UDP flow, WRR Scheduling

Congestion Collapse

Classical – results from unnecessary retransmissions of packets First reported in mid 1980s, due to retransmission of

packets that were in transit or already received Corrected by timer improvements and congestion control in

modern TCP implementations From undeliverable packets – bandwidth wasted by

delivering packets that will eventually be dropped Largest unresolved danger Condition is not stable, it returns to normal once load is

reduced Not an issue in a circuit-switched network – a sender can

only send when a path exists with the necessary bandwidth

Congestion Collapse Simulations(top line = Bold line: Aggregate Goodput)

Congestion Collapse Simulations

Other forms of congestion collapse Fragmentation-based – network transmits fragments or cells that

are discarded because they can’t be reassembled into a valid packet ATM uses Early Packet Discard – when a cell is dropped, a

complete frame is dropped Variant is packets received by transport-level, then later

discarded before used by user Occurs when web users abort transfers due to delays, then re-

request the same data Increased control traffic – an increasing fraction of the bytes

transmitted belong to control traffic, and a decreasing fraction of the bytes are data for applications Control packets – packet headers for small data packets, routing

updates, multicast join an prune messages, session messages, DNS messages, etc

Incentives to use Congestion Control The current Internet “rewards” users that do not use

congestion control, they might get a larger fraction of the bandwidth

Incentives cannot come from other users, they need to come from the network

Two ways to prevent congestion collapse from undeliverable packets End-to-end congestion control, possibly by using incentives

at routers Use of virtual-circuits, where packets only enter the

network if they can reach their final destination

Identifying flows to regulate

Designed to detect a small number of misbehaving flows

An incentive to limit the benefits of not using congestion control

Issues not addressed encryption and fragmentation make it more

difficult to classify packets into flows IPsec could prevent routers from using source IP

addresses and port numbers

Identifying flows that are not TCP-friendly

T = maximum sending rate (Bps) B = size of packets (bytes) R = roundtrip time (s)

No simple test for this p = packet drop rate Use this equation to calculate the maximum arrival

rate from a conformant TCP connection in similar circumstances

Identifying unresponsive flows TCP-friendly test is based on TCP, routers may want to consider other

protocols One approach is to verify that a high-bandwidth flow was responsive (its

arrival rate drops when its packet drop rate increases) If drop rate increases by x, and the load does not decrease by a factor

close to √x or more, the flow is unresponsive Requires estimates of a flow’s arrival rate and packet drop rate over several

long time intervals Arrival rate estimated from packet drops from active queue management Drop rate estimate using aggregate drop rate of the queue

Only applied to high bandwidth flows Incentive to start with an overly-high initial bandwidth, so it would get

larger share of bandwidth even after it is reduced Example test: if drop rate increases by a factor of four, but arrival rate

has not decreased to below 90% of its previous value

Identifying unresponsive flows Other tests

Flows with an increasing or constant average arrival rate, while the router drop rate is increasing

Flows whose average arrival rate tracks changes in the router drop rate

Flows whose average arrival rate changes independently of the router drop rate

Identifying flows using disproportionate bandwidth Router might restrict bandwidth of flows even

if they are using congestion control If it is the only TCP

with sustained demand using large windows with significantly smaller roundtrip time with larger packet sizes

Identifying flows using disproportionate bandwidth A flow uses disproportionate share if

Arrival rate > log(3n)/n log(3n)/n is close to one (0.9) for n=2 Grows slowly as a multiple of 1/n

A flow has a high arrival rate relative to the level of congestion if Arrival rate > c/√p Bps

Alternate Approaches

Deploy per-flow scheduling mechanisms such as RR or FQS at all congested routers

Problem with per-flow scheduling Encourages flows to make sure their queue never get

empty – so they lose their turn at scheduling FCFS advantages

More efficient to implement – link speeds and active flows are increasing

Allows packets arriving in a small burst to be transmitted in a burst, in stead of spread out by the scheduler

Alternate Approaches

FCFS with per-flow scheduling FCFS with differential dropping for flows using

large fraction of bandwidth Scheduling mechanisms such as Class-Based

Queuing or Stochastic Fair Queuing that can operate on levels other that a single flow or all of the traffic

Min-max fairness restricts attention to each component It would be better to consider the number of

congested links on each flow’s path

Alternate Approaches

Pricing structures State required for this would be complex

Conclusions and future work

Arguments for The need for end-to-end congestion control The need for mechanisms in the network to detect

and restrict unresponsive or high-bandwidth best-effort flows

Future Work A specific proposal for mechanisms to identify and

control unresponsive flows The specifics are not as important as deployment

of a mechanism