Congestion Control Created by M Bateman, A Ruddle & C Allison As part of the TCP View project

Overview Congestion sources Congestion Collapse Congestion control basic

Congestion Different sources compete for resources inside the network Why is it a problem –Sources are unaware of current state of resource –Sources are unaware of each other Manifestations –Lost packets –Long delays –In many situations will result in < 1.5 Mbps of throughput for the above topology (congestion collapse)

Congestion Collapse Increase in network load results in decrease of useful work done Many possible causes –Spurious retransmissions of packets still in flight Classical congestion collapse How can this happen with packet conservation Better timer and TCP congestion control –Undelivered packets Packets consume resources and are dropped elsewhere Congestion control for all traffic

Congestion Collapse Fragments –Mismatch of transmission and retransmission units –Solutions Make network drop all fragments of a packet Do path MTU discovery Control traffic – large amount –Headers, routing messages, DNS, etc Stale or unwanted packets –Packets that are delayed on long queues –‘Push’ data that is never used

Costs of Congestion Large queuing delay as near link capacity Retransmits to replace dropped packets Spurious retransmits due to delayed packets Wasted work ‘upstream’ for packet that is eventually dropped

Congestion Control and Avoidance A mechanism which –Uses network resources efficiently –Preserves fair network resource allocation –Prevents or avoids collapse Congestion collapse is not just a theory –Has been frequently observed

Approaches End-to-End No explicit feedback from network Congestion inferred from end-system observed loss, delay Approach taken by TCP Network Assisted Routers provide feedback to end systems –Single bit indicating congestion –Explicit rate sender should send at Makes routers complicated

E.g. TCP Congestion Control Very simple mechanisms in network –FIFO scheduling with shared buffer pool –Feedback through packet drops TCP interprets packet drops as sign of congestion and slows down –Assumes packet loss is a sign of congestion Wireless network! Periodically probes the network to check whether more bandwidth has become available

Congestion Control Objectives Simple router behaviour Distributed Efficiency Fairness Convergence: control system must be stable

Basic Control Model Reduce speed when congestion is perceived –How is congestion signalled Either mark or drop packets –How much to reduce Increase speed otherwise –Probe for available bandwidth – how?

Linear Control Many different possibilities for reaction to congestion and probing –Examine simple linear controls Window(t+1) = a +b Window(t) Different a/b for increases and a d /b d for decrease Supports various reaction to signals –Increase/decrease additively –Increased/decrease multiplicatively –Which of the four combinations is optimal

TCP Congestion Control Changes to TCP motivated by ARPANET congestion collapse Basic principles –AIMD –Packet conservation –Reaching steady state quickly –ACK clocking

AIMD Distributed, fair and efficient Packet loss is seen as sign of congestion and results in a multiplicative rate decrease –Factor of 2 TCP periodically probes for available bandwidth by increasing its rate

Implementation Issues Operating system timers are very course –How to pace packets out smoothly Implemented using a congestion window that limits how much data can be in the network –TCP also keeps track of how much data is in transit Data can only be sent when the amount outstanding data is less than the congestion window –The amount of outstanding data increased on a “send” and decreased on “ack” –(last sent – last acked) < congestion window Window limited by both congestion and buffering –Sender’s maximum window = Min (advertised window, cwnd)

Congestion Avoidance If loss occurs when cwnd = W –Network can handle 0.5W ~ W segments –Set cwnd to 0.5W (multiplicative decrease) Upon receiving ACK –Increase cwnd by 1/cwnd Implements AIMD

TCP Flavours Tahoe, Reno, Vegas TCP Tahoe (distributed with 4.3BSD) –Original implementation of Van Jacobson’s mechanism –Includes: Slow start Congestion avoidance Fast retransmit

What are duplicate ACKs? –Repeated acks for same sequence When can duplicate ACKs occur? –Loss –Packet re-ordering –Window update – ads of new flow control window Assume re-ordering is infrequent and not of large magnitude –Use receipt of 3 or more duplicate ACKs as indication of loss –Don’t wait for timeout to retransmit packet

TCP Reno (1990) All mechanism of Tahoe Addition of fast-recovery –Opening up congestion window after fast retransmit Delayed ACKs Header predication –Implementation designed to improve performance –Has common case code inlined With multiple losses, Reno typically timeouts because it does not see dup ACKs

Fast Recovery Each duplicate ACK notifies sender that single packet has cleared network When < cwnd packet are outstanding –Allow new packet out with each new duplicate acknowledgement Behaviour –Sender is idle for some time – waiting for ½ cwnd worth of dupacks –Transmits at original rate after wait ACK clocking rate is same as before loss