TCP congestion control

TTCCPP
CCoonnggeessttiioonn CCoonnttrrooll
Lecture material taken from
“Computer Networks A Systems Approach”,
Fourth Edition,Peterson and Davie,
Morgan Kaufmann, 2007.
Computer Networks: TTCCPP CCoonnggeessttiioonn CCoonnttrrooll 11

TTCCPP CCoonnggeessttiioonn CCoonnttrrooll
• Essential strategy :: The TCP host sends
packets into the network without a reservation
and then the host reacts to observable events.
• Originally TCP assumed FIFO queuing.
• Basic idea :: each source determines how
much capacity is available to a given flow in the
network.
• ACKs are used to ‘pace’ the transmission of
packets such that TCP is “self-clocking”.

AAIIMMDD
((AAddddiittiivvee IInnccrreeaassee // MMuullttiipplliiccaattiivvee
DDeeccrreeaassee))
• CongestionWindow (cwnd) is a variable held by
the TCP source for each connection.
MaxWindow :: min (CongestionWindow , AdvertisedWindow)
EffectiveWindow = MaxWindow – (LastByteSent -LastByteAcked)
• cwnd is set based on the perceived level of
congestion. The Host receives implicit (packet
drop) or explicit (packet mark) indications of
internal congestion.

AAddddiittiivvee IInnccrreeaassee ((AAII))
• Additive Increase is a reaction to perceived available
capacity (referred to as congestion avoidance stage).
• Frequently in the literature, additive increase is defined
by parameter α (where the default is α = 1).
• Linear Increase :: For each “cwnd’s worth” of packets
sent, increase cwnd by 1 packet.
• In practice, cwnd is incremented fractionally for each
arriving ACK.
increment = MSS x (MSS /cwnd)
cwnd = cwnd + increment

Source Destination
Add one packet
each RTT
FFiigguurree 66..88 AAddddiittiivvee IInnccrreeaassee

MMuullttiipplliiccaattiivvee DDeeccrreeaassee ((MMDD))
* Key assumption :: a dropped packet and resultant
timeout are due to congestion at a router.
• Frequently in the literature, multiplicative decrease
is defined by parameter β (where the default is β =
0.5)
Multiplicate Decrease:: TCP reacts to a timeout by
halving cwnd.
• Although defined in bytes, the literature often
discusses cwnd in terms of packets (or more
formally in MSS == Maximum Segment Size).
• cwnd is not allowed below the size of a single
packet.

AAIIMMDD
((AAddddiittiivvee IInnccrreeaassee // MMuullttiipplliiccaattiivvee
DDeeccrreeaassee))
• It has been shown that AIMD is a necessary
condition for TCP congestion control to be stable.
• Because the simple CC mechanism involves
timeouts that cause retransmissions, it is important
that hosts have an accurate timeout mechanism.
• Timeouts set as a function of average RTT and
standard deviation of RTT.
• However, TCP hosts only sample round-trip time
once per RTT using coarse-grained clock.

FFiigguurree 66..99 TTyyppiiccaall TTCCPP
SSaawwttooootthh PPaatttteerrnn
60
50
40
20
1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0
Time (seconds)
70
30
10
10.0

SSllooww SSttaarrtt
• Linear additive increase takes too long to
ramp up a new TCP connection from cold
start.
• Beginning with TCP Tahoe, the slow start
mechanism was added to provide an initial
exponential increase in the size of cwnd.
Remember mechanism by: slow start
prevents a slow start. Moreover, slow start
is slower than sending a full advertised
window’s worth of packets all at once.

SSllooww SSttaarrtt
• The source starts with cwnd = 1.
• Every time an ACK arrives, cwnd is
incremented.
cwnd is effectively doubled per RTT “epoch”.
• Two slow start situations:
 At the very beginning of a connection {cold start}.
 When the connection goes dead waiting for a
timeout to occur (i.e, the advertized window goes
to zero!)

Source Destination
Slow Start
Add one packet
per ACK
FFiigguurree 66..1100 SSllooww SSttaarrtt

SSllooww SSttaarrtt
• However, in the second case the
source has more information. The
current value of cwnd can be saved as
a congestion threshold.
• This is also known as the “slow start
threshold” ssthresh.

ssthresh

FFiigguurree 66..1111 BBeehhaavviioorr ooff TTCCPP
CCoonnggeessttiioonn CCoonnttrrooll
60
50
40
20
1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0 9.0
Time (seconds)
70
30
10

FFaasstt RReettrraannssmmiitt
• Coarse timeouts remained a problem, and Fast
retransmit was added with TCP Tahoe.
• Since the receiver responds every time a packet
arrives, this implies the sender will see duplicate
ACKs.
Basic Idea:: use duplicate ACKs to signal lost packet.
Fast Retransmit
Upon receipt of three duplicate ACKs, the TCP Sender
retransmits the lost packet.

FFaasstt RReettrraannssmmiitt
• Generally, fast retransmit eliminates about half
the coarse-grain timeouts.
• This yields roughly a 20% improvement in
throughput.
• Note – fast retransmit does not eliminate all
the timeouts due to small window sizes at the
source.

Sender Receiver
ACK 2
FFiigguurree 66..1122 FFaasstt RReettrraannssmmiitt
Packet 1
Packet 2
Packet 3
Packet 4
Packet 5
Packet 6
Retransmit
packet 3
ACK 1
ACK 2
ACK 2
ACK 2
ACK 6
Fast Retransmit
Based on three
duplicate ACKs

FFiigguurree 66..1133 TTCCPP FFaasstt RReettrraannssmmiitt
TTrraaccee
60
50
40
20
1.0 2.0 3.0 4.0 5.0 6.0 7.0
Time (seconds)
70
30
10

FFaasstt RReeccoovveerryy
• Fast recovery was added with TCP Reno.
• Basic idea:: When fast retransmit detects
three duplicate ACKs, start the recovery
process from congestion avoidance region
and use ACKs in the pipe to pace the
sending of packets.
Fast Recovery
After Fast Retransmit, half cwnd and commence
recovery from this point using linear additive increase
‘primed’ by left over ACKs in pipe.

MMooddiiffiieedd SSllooww SSttaarrtt
• With fast recovery, slow start only
occurs:
–At cold start
–After a coarse-grain timeout
• This is the difference between
TCP Tahoe and TCP Reno!!

MMaannyy TTCCPP ‘‘ffllaavvoorrss’’
• TCP New Reno
• TCP SACK
– requires sender and receiver both to
support TCP SACK
– possible state machine is complex.
• TCP Vegas
– adjusts window size based on difference
between expected and actual RTT.
• TCP Cubic
CCoommppuutteerr NNeettwwoorrkkss:: TTCCPP CCoonnggeessttiioonn CCoonnttrrooll 2211

FFiigguurree 55..66 TThhrreeee--wwaayy TTCCPP
HHaannddsshhaakkee

AAddaappttiivvee RReettrraannssmmiissssiioonnss
RTT:: Round Trip Time between a pair of
hosts on the Internet.
• How to set the TimeOut value (RTO)?
– The timeout value is set as a function of
the expected RTT.
– Consequences of a bad choice?

OOrriiggiinnaall AAllggoorriitthhmm
• Keep a running average of RTT and
compute TimeOut as a function of this
RTT.
– Send packet and keep timestamp ts .
– When ACK arrives, record timestamp ta .
SampleRTT = ta - ts

OOrriiggiinnaall AAllggoorriitthhmm
Compute a weighted average:
EEssttiimmaatteeddRRTTTT == αα xx EEssttiimmaatteeddRRTTTT ++
((11-- αα)) xx SSaammpplleeRRTTTT
Original TCP spec: αα iinn rraannggee ((00..88,,00..99))
TTiimmeeOOuutt == 22 xx EEssttiimmaatteeddRRTTTT

KKaarrnn//PPaarrttiiddggee AAllggoorriitthhmm
An obvious flaw in the original algorithm:
Whenever there is a retransmission it is
impossible to know whether to associate
the ACK with the original packet or the
retransmitted packet.

FFiigguurree 55..1100 AAssssoocciiaattiinngg tthhee
AACCKK??
Sender Receiver
Original transmission
Retransmission
ACK
Sender Receiver
Original transmission
ACK
Retransmission
(a) (b)

KKaarrnn//PPaarrttiiddggee AAllggoorriitthhmm
1. Do not measure SSaammpplleeRRTTTT when
sending packet more than once.
2. For each retransmission, set TTiimmeeOOuutt
to double the last TTiimmeeOOuutt.
{ Note – this is a form of exponential
backoff based on the believe that the
lost packet is due to congestion.}

JJaaccoobbssoonn//KKaarreellss AAllggoorriitthhmm
The problem with the original algorithm is that it did not
take into account the variance of SampleRTT.
DDiiffffeerreennccee == SSaammpplleeRRTTTT –– EEssttiimmaatteeddRRTTTT
EEssttiimmaatteeddRRTTTT == EEssttiimmaatteeddRRTTTT ++
((δδ xx DDiiffffeerreennccee))
DDeevviiaattiioonn == δδ ((||DDiiffffeerreennccee|| - DDeevviiaattiioonn))
where δδ is a fraction between 0 and 1.

JJaaccoobbssoonn//KKaarreellss AAllggoorriitthhmm
TCP computes timeout using both the mean
and variance of RTT
TTiimmeeOOuutt == μμ xx EEssttiimmaatteeddRRTTTT
++ ΦΦ xx DDeevviiaattiioonn
where based on experience μμ == 11 and ΦΦ == 44.

TTCCPP CCoonnggeessttiioonn CCoonnttrrooll
SSuummmmaarryy
• TCP interacts with routers in the subnet
and reacts to implicit congestion
notification (packet drop) by reducing the
TCP sender’s congestion window.
• TCP increases congestion window using
slow start or congestion avoidance.
• Currently, the two most common versions
of TCP are New Reno and Cubic

TTCCPP NNeeww RReennoo
• Two problem scenarios with TCP Reno
– bursty losses, Reno cannot recover from
bursts of 3+ losses
– Packets arriving out-of-order can yield
duplicate acks when in fact there is no
loss.
• New Reno solution – try to determine
the end of a burst loss.

• When duplicate ACKs trigger a
retransmission for a lost packet,
remember the highest packet sent from
window in recover.
• Upon receiving an ACK,
– if ACK < recover => partial ACK
– If ACK ≥ recover => new ACK

• Partial ACK implies another lost packet:
retransmit next packet, inflate window
and stay in fast recovery.
• New ACK implies fast recovery is over:
starting from 0.5 x cwnd proceed with
congestion avoidance (linear increase).
• New Reno recovers from n losses in n
round trips.

TCP congestion control

Related slideshows

More Related Content

TCP congestion control