Outline
- congestion control
- congestion control for TCP: slow start, AIMD
- fairness
Congestion Control Basics
- packets may be dropped for many reasons, including misconfigured
routers, backhoes, lightning, and so on
- one reason a packet may be dropped is congestion: the output
queue on a router is full, so the packet is not added to the queue
- this is the only reason the transport protocol can directly affect
- a single connection can cause congestion if a router has to send
on an outgoing link that is slower than all the preceding links: on a
bottleneck link
- multiple connections, each of which could be carried, might
together result in congestion, just like a highway at rush hour
- it is considered desirable for the end-systems to reduce their
sending rate to a point where they do not cause (too much) congestion
Router Queues and Congestion Collapse
- packet drops due to congestion could be avoided if routers
had unlimited queues
- even aside from the practical difficulty of achieving this,
unlimited queues would lead to unlimited delays in data delivery
- eventually the sender would time out and retransmit, adding
to the network load
- in other words, the offered load increases, due to
retransmissions, whenever packets are dropped or overly delayed
- this increase in offered load when there is congestion has
twice led to congestion collapse in the Internet
- in congestion collapse, the senders retransmit packets that
are delayed or have been dropped, leading to greater offered load
Approaches to Congestion Control
- if the network is experiencing congestion, senders should
slow down their send rate
- how does the sender know whether the connection (or, more generally,
the flow) is encountering congestion?
- either the sender detects the congestion, or the network must
communicate to the sender that the network is congested
Network Feedback for Congestion
- the congestion can be detected at a router (or a switch)
by watching queue sizes
- this router can send a message to the sender requesting it
to slow down
- this provides fast feedback, but generates additional messages
(and additional work for the router) just when the network is congested
- or, this router can modify the message being sent to record
that congestion is occurring
- the receiver can then return the information to the sender in
the ack packets
- this requires at least one round-trip-time to give feedback
- but the router can give feedback as soon as the queue starts to
grow, so it might not have to drop packets
- this is the strategy used by the TCP/IP Explicit Congestion
Notification, ECN
- the router sets a field in the IP header to record that the packet
encountered congestion
- the receiver sets the corresponding ECE bit (ECN-Echo) in the TCP header
of the acks
- the sender then slows down, and sets the CWR (Congestion Window Reduced)
bit in the header of packets sent in the forward direction
End-System Detection of Network Congestion
- When the network is sufficiently congested, it begins to
drop packets
- one round-trip-time later, the sender will notice that packets
have been lost
- the sender can then slow down
- afterwards, the sender will slowly speed up, until
packets are dropped again
- another measure of network congestion is increased delay (RTT)
due to longer queues in the routers
- may be hard to get a good baseline (no congestion), so instead
use the lowest measured RTT
- as long as the RTT is near the minimum, there should be no
significant congestion
- if the RTT is near the minimum, slowly increase the sending
rate
- if the RTT is significantly above the minimum, slowly decrease
the sending rate
Internet Congestion collapse
- in the 1970s and early 1980s, the Internet more than once
suffered from a strange failure:
- many links were busy carrying data
- router queues were generally full
- but many people could not communicate successfully over the Internet
because the router queues were full, this was called congestion collapse,
- but the exact cause was not clear
- eventually people realized that:
- when a TCP packet is dropped, that schedules one or more retransmissions
- so when the network is congested, the traffic increases automatically
(dropping packets does not reduce overall load)
- causing more congestion
- there is not much that can be done about this at the router level,
so researchers started looking at the end-point
Congestion Control for TCP
- TCP has a way of controlling (throttling) send speed: the
flow control window
- one possibility would be to ask the routers to modify (reduce)
the window when a packet experiences congestion
- this is impractical for two reasons:
- it requires the routers to decode the TCP header of all packets
carried, which increases computational load on the routers
- the window values are carried in the ack packet, the congestion is
(usually) experienced in the forward direction
- the current IP ECN (Explicit Congestion Notification) mechanism
gets around these problems by putting the congestion notification bits
in the IP header, and requiring the receiving host to tell the TCP sender
- at the time, IP ICN had not been developed, so an alternative was
found
- when there is congestion, packets are dropped
- a TCP sender should interpret packet drop as a sign of congestion,
and reduce its send window below the value set by the flow control window,
to the value of the congestion window
TCP Congestion Control Slow Start
- TCP Reno (a modification of TCP Tahoe)
- a TCP connection begins with a congestion window of one Maximum
Segment Size, 1 MSS
- every time an ack is received, the window is increased by the amount
of data being acked
- if one congestion window is sent every RTT, at the end of the
RTT, the congestion window should have doubled
- the congestion window grow exponentially
- this is called Slow Start, and continues until either:
- a packet loss is detected, or
- a predetermined threshold is reached
- the packet loss is detected by either a timeout, or a
fast retransmission/fast recovery following three duplicate acks
- when a packet loss is detected:
- the threshold is set to half the current congestion window,
- the congestion window is set to 1 (if timeout) or threshold
(if fast recovery)
- slow start continues or begins
Additive Increase, Multiplicative Decrease
- exponential growth is very fast, and may itself cause congestion
- sending faster is an experiment: the window at which the packet is
dropped is experimentally determined to be unsustainable
- but what rate is sustainable?
- probably, but not certainly, half of the window at which the packet
was dropped
- if the timeout occurred, be conservative, and use slow start to
reach the threshold
- if fast recovery occurred, be a little more aggressive, and start
at the threshold
- and then, increase slowly, to probe the network
- until another packet loss is detected
- then again set the threshold to half the congestion window, and
begin either slow start or linear increase
- this is Additive Increase, Multiplicative Decrease, AIMD
- it has been shown that any strategy that relies on packet loss and
decreases more slowly than Multiplicatively is not stable, i.e. leads
to congestion collapse
- assuming that 1 congestion window is sent every RTT, and
- we would like to increase by 1 MSS every RTT, so the increase
per data acked should be:
MSS * (data acked) / congestion window
- in a proposed alternative, TCP Vegas, TCP keeps track of
round-trip times, and if they increase above the minimum measured,
the window is decreased linearly
- this linear decrease is assumed to work because it does not cause
as much congestion as the traditional AIMD
Macroscopic TCP throughput
- under AIMD, the window is cut in half when the peak throughput is
reached
- and then the window grows by one MSS every RTT, until it reaches
the same sending rate
- assume the network throughput is a constant B
- ignoring slow start, TCP will oscillate between througputs of
B/2 and B, with a mean of 3/4 B
- since one window is sent every RTT, and assuming W = B/RTT, the
window will vary between W/2 and W, with a mean of 3/4 W
- this was first presented in 1997
- a more recent note
by one of the same authors suggests the Internet is relying less on
end-system cooperation, and more on bandwidth limitations at the access
link
TCP Congestion Control Fairness
- data that is not congestion controlled, such as UDP, can
crowd out data that is "well behaved"
- newer transport protocols, such as Stream Control Transport
Protocol (SCTP) and the Datagram Congestion Control Protocol
try to make UDP "behave well"
- multiple TCP connections that have the same bottleneck link,
flow control window, and RTT, tend to converge to the same range
of congestion control windows
- but connections that have longer (slower) RTTs will get a lower
share of the bandwidth than connections with shorter RTTs
- and connections are free! anyone wanting a higher share of
the bandwidth can simply open more connections