1

CS242 Computer Networks Department of Computer Science Wellesley College

TCP congestion control The Reno algorithm

TCP congestion control 12-2

Recall from last time o  TCP's approach is an end-

to-end congestion control receives no explicit support from the network layer. The transport layer does it all.

o  This is in contrast to network-assisted congestion control which we saw in reading.

TCP congestion control 12-3

TCP congestion window o  Each side of a TCP

connection maintains a congestion window variable CongWin that constrains the rate at which a sender can shovel traffic into the network.

o  Specifically, LastByteSent - !

!LastByteAcked ≤ min{CongWin,RcvWindow)!

TCP congestion control 12-4

Controlling transmission rate o  Ignoring the role of RcvWindow for the moment, the

amount of unacknowledged data at a sender is limited by LastByteSent - LastByteAcked ≤ CongWin!

o  At the beginning of each round-trip time, the sender is limited to send CongWin bytes. These are acknowledged at the end of the RRT.

o  Thus sender’s rate is roughly CongWin/RTT bytes/sec.

2

TCP congestion control 12-5

Measuring network congestion o  Senders perceive

network congestion through either a timeout or the receipt of three duplicate ACKs from the receiver*.

o  TCP’s basic plan is to keep speeding up until it perceives network congestion, then back off real quick.

*We term a timeout or receipt of three duplicate ACKs a loss event. TCP congestion control 12-6

Additive-increase, Multiplicative-decrease

o  If there is no detected congestion (no loss), then TCP increases CongWin by one Maximum Segment Size (MSS) each RTT, reasoning that there is probably unused bandwidth available.

o  When a loss event occurs, TCP cuts CongWin in half, but never lets it fall below one MSS.

Team work o  Since other TCP connections

that are passing through the same congested routers are also likely to be experiencing loss events, they too are likely to reduce their sending rates by decreasing their own values of CongWin.

o  The overall effect is for sources with paths through the congested routers to reduce the rate at which they send traffic into the network.

o  Actually, things are a little more complicated, as we will see.

TCP congestion control 12-7 TCP congestion control 12-8

Slow start o  When a TCP connection

begins, CongWin is set to one MSS.

o  However, an acceleration rate of one MSS per RTT would almost certainly waste bandwidth.

o  Instead, TCP starts slow, then doubles CongWin each RTT until there is a loss event, at which point Congwin is cut in half and all is as before.

3

TCP congestion control 12-9

It's kinda cool how TCP slow starts* o  TCP sends the first segment into the network and waits for an

acknowledgment. o  If this segment is acknowledged before a loss event, the TCP

sender increases the congestion window by one MSS and sends out two MSS segments.

o  If these are acknowledged before loss events, the sender increases the congestion window by one MSS for each of the acknowledged segment, giving a congestion window of four MSS, and sends out four MSS segments.

o  This procedure continues as long as the acknowledgements arrive before a loss event.

*A bit of a misnomer since the value of the CongWind effectively doubles every RTT during this phase.

TCP congestion control 12-10

Reacting to loss events (in more detail) o  The sender receives three

ACKs for the same packet. (At least some segments are getting through.)

o  No response from the receiver and a timeout occurs. (This is potentially more troubling.)

o  TCP responds differently to each type of loss event.

TCP congestion control 12-11

Reaction to timeout events o  After a timeout, a TCP

sender enters a slow-start phase, then grows exponentially until CongWin reaches a Threshold value, with linear growth after that.

o  Threshold value is initially set to a very large value, so it has no initial effect.

o  When timeout occurs, Threshold set to CongWin/2 and CongWin is set to 1 MSS.

TCP congestion control 12-12

TCP Reno reacts to 3 duplicate ACKs o  TCP Tahoe did not

distinguish between loss events.

o  However, something getting through is probably better than nothing, so TCP Reno cancels the slow-start phase for triple ACKs.

o  When a triple duplicate ACK occurs, Threshold set to CongWin/2 and CongWin set to Threshold + 3.

4

TCP congestion control 12-13

See for yourself

TCP congestion control 12-14

Once things get going: TCP average throughput o  TCP transmission rate is

roughly w/RTT where w is the current value of CongWin.

o  Assume RTT and the value of CongWin when a loss occurs, W, are relatively constant over the duration of the connection.

o  Then TCP repeatedly increases linearly between W/(2•RTT) and W/RTT.

FSM description of TCP congestion control

TCP congestion control 12-15 TCP congestion control 12-16

Fairness o  Consider K TCP

connections, each with a different end-to-end paths, but all passing through the same bottleneck link at R bps and all with big jobs to do.

o  A congestion-control mechanism is said to be fair if the average transmission rate of each connection is approximately R/K.

5

Congestion control 12-17

Finite buffers and multihop paths All hosts have the same

rates, times outs, and use retransmission.

All routers have links with capacity R and finite shared

output buffers

Congestion control 12-18

Light loads For small λin,

buffer overflows are rare and throughput

approximately equals the

offered load.

Small increases in λin result in corresponding increases

in λout.

Congestion control 12-19

Okay, so suppose traffic is heavy A to C traffic

arriving to router R2 can have an arrival

rate of at most R, the

capacity of the link from R1 to R2, regardless of the value of

λin ...

As λin' increases, B to D traffic

begins to fill R2's buffer and A to C

rates drop.

... while B to D traffic has no

such restriction and can arrive at

R2 at a rate of λin

Congestion control 12-20

Not fair!

A to C end to end throughput goes to zero and all

the work done by R1 is wasted

6

Congestion control 12-21

One additional cost of dropping packets

When a packet is dropped along a path, the transmission capacity that was used at each of the upstream routers to forward that packet to the point at which it is dropped ends up having been wasted.

TCP congestion control 12-22

Is TCP fair? o  Consider two TCP connections sharing a link with

transmission rate R and no one else is around. o  Assume both have the same MSS and RTT (hence same

CongWin), and both have big jobs.

TCP congestion control 12-23

Throughput realized by TCP connections

Suppose TCP window sizes are such that the two connections realize throughputs

indicated by A

TCP congestion control 12-24

Linear growth

Because the amount of link bandwidth jointly consumed by A & B

is less than R, no loss and both will grow

their windows by 1 MSS per RTT

moving along this 45 degree line.

7

TCP congestion control 12-25

Fall back to a slightly fairer position & repeat

Eventually the line cross full bandwidth utilization and losses

occur.

Both cut their windows in half & throughput falls to point C, ½ way along a vector starting at B and ending at the origin.

Things aren't always so fair o  When multiple connections

share a common bottleneck, those with smaller RTT are able to grab available bandwidth more quickly.

o  But wait, it gets better ...

TCP congestion control 12-26

TCP congestion control 12-27

The tragedy of the common o  Web browsers often use

multiple parallel TCP connections to transfer objects within a Web page.

o  UDP doesn’t even try to adjust their transmission rates.