1. Chapter 3 Transport Layer
Part 4: Congestion control
Computer Networking: A Top Down Approach 6th edition Jim Kurose, Keith Ross Addison-Wesley March 2012
Transport Layer

2. Chapter 3: Transport Layer
Our goals:
understand principles behind transport layer services:
multiplexing/demultiplexing
reliable data transfer
flow control
congestion control
learn about transport layer protocols in the Internet:
UDP: connectionless transport
TCP: connection-oriented transport
TCP congestion control
Transport Layer

3. Chapter 3 outline 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing
3.3 Connectionless transport: UDP
3.4 Principles of reliable data transfer
3.5 Connection-oriented transport: TCP
segment structure
reliable data transfer
flow control
connection management
3.6 Principles of congestion control
3.7 TCP congestion control
Transport Layer

4. Principles of Congestion Control
informally: “too many sources sending too much data too fast for network to handle”
different from flow control!
manifestations:
lost packets (buffer overflow at routers)
long delays (queueing in router buffers)
a top-10 problem!
Transport Layer

5. Causes/costs of congestion: scenario 1
Host A and Host B’s each transmit at an average rate of λin bytes/sec (e.g. 50MBs)
Causes/costs of congestion: scenario 1
Receiver takes in at a rate of λout bytes/sec
original data: lin
throughput: lout
two senders, two receivers
one router, infinite buffers
output link capacity: R
no retransmission
Host A
unlimited shared output link buffers
Host B
Link capacity is R
Result of sharing link between two Hosts
R/2
delay
lin
When λin> R/2 the average number of queued packets in the router is unbounded and the average delay between source and destination becomes infinite
R/2
lout
lin
Note that these scenarios are back-of-the-envelop, not precise analysis
Throughput
maximum per-connection throughput: R/2
large delays as arrival rate, lin, approaches capacity
Transport Layer

6. Causes/costs of congestion: scenario 2
one router, finite buffers
sender retransmission of timed-out packet
application-layer input = application-layer output: lin = lout
transport-layer input includes retransmissions : lin lin
λ` is called the offered load ‘
performance depends on how retransmission is done!
lin : original data
lout
l'in: original data, plus retransmitted data
Host A
finite shared output link buffers
Host B
Transport Layer

7. Causes/costs of congestion: scenario 2
Max average throughput is R/2 since no packets are lost
R/2
lout
lin
idealization: perfect knowledge
sender sends only when router buffers available
λin = λin` since we only send segment if we know there is buffer space
lin : original data
lout
copy
l'in: original data, plus retransmitted data A
free buffer space!
finite shared output link buffers
Host B
Transport Layer

8. Causes/costs of congestion: scenario 2
Idealization: known loss packets can be lost, dropped at router due to full buffers
sender only resends if packet known to be lost
lin : original data
lout
copy
l'in: original data, plus retransmitted data A
no buffer space!
Host B
Transport Layer

9. Causes/costs of congestion: scenario 2
Idealization: known loss packets can be lost, dropped at router due to full buffers
sender only resends if packet known to be lost
R/2
lin
lout
when sending at R/2, some packets are retransmissions but asymptotic goodput is still R/2 (why?)
lin : original data
lout
l'in: original data, plus retransmitted data A
free buffer space!
Assumption: On average out of 0.5R units sent, 0.166R bytes/sec are retrans and 0.333R are original
Host B
Transport Layer

10. Causes/costs of congestion: scenario 2
Realistic: duplicates
packets can be lost, dropped at router due to full buffers
sender times out prematurely, sending two copies, both of which are delivered
R/2
when sending at R/2, some packets are retransmissions including duplicated that are delivered!
lout
lin
R/2
timeout
lin
Assuming (for no good reason) that on average each packet is forwarded twice
lout
copy
l'in A
free buffer space!
May time-out prematurely and retrans a packet that is delayed in the queue
Receiver will receive multiple copies of some packets
Host B
Transport Layer

11. Causes/costs of congestion: scenario 2
Realistic: duplicates
packets can be lost, dropped at router due to full buffers
sender times out prematurely, sending two copies, both of which are delivered
R/2
when sending at R/2, some packets are retransmissions including duplicated that are delivered!
lout
lin
R/2
“costs” of congestion:
more work (retrans) for given “goodput”
unneeded retransmissions: link carries multiple copies of pkt
decreasing goodput
Transport Layer

12. Causes/costs of congestion: scenario 3
Q: what happens as lin and lin’ increase ?
four senders
multihop paths
timeout/retransmit
A: as red lin’ increases, all arriving blue pkts at upper queue are dropped, blue throughput g 0
Host A
lout
lin : original data
Host B
l'in: original data, plus retransmitted data
finite shared output link buffers R1
Host D R2
Host C
Transport Layer

13. Low traffic Extremely small values of l
Buffer overflows rare
Throughput approx equals offered load
i.e., =
With slightly larger values of
increases the same
since buffer overflows are still rare l in
Consider connection A to C that goes through routers R1 and R2
A-C shares router R1 with D-B
A-C shares router R2 with B-D l in l in l
out l in l
out
Transport Layer

14. Large traffic Will get extremely large values of from B-D l
This will overflow R2
segments from A through R1 to R2 will tend to get discarded.
Result: throughput from A to C will go towards 0
See next slide l in ‘
A - C that goes through routers R1 and R2
A-C shares router R2 with B-D
Transport Layer

15. Causes/costs of congestion: scenario 3
Host A
lout
Host B
another “cost” of congestion:
when packet dropped, any “upstream transmission capacity used for that packet was wasted!
i.e., when R2 drops a packet from R1, R1’s transmission was wasted!
Transport Layer

16. Approaches towards congestion control
two broad approaches towards congestion control:
end-end congestion control:
no explicit feedback from network
congestion inferred from end-system observed loss, delay
approach taken by TCP
network-assisted congestion control:
routers provide feedback to end systems
Method 1: single bit indicating congestion (SNA, DECbit, TCP/IP ECN (proposed), ATM)
Method 2: router gives explicit rate sender should transmit
ATM (asynchronous transfer mode) is a dedicated-connection switching technology that organizes digital data into 53-byte cell units and transmits them over a physical medium using digital signal technology. Individually, a cell is processed asynchronously relative to other related cells and is queued before being multiplexed over the transmission path.
ATM was thought to be “the” networking technology for the internet in the late 90’s. Very popular with the telcom’s
Transport Layer

17. Case study: ATM* ABR congestion control
ABR: available bit rate:
“elastic service”
if sender’s path “underloaded”:
sender should use available bandwidth
if sender’s path congested:
sender throttled to minimum guaranteed rate
RM (resource management) cells:
sent by sender, interspersed with data cells (~1 every 32 data cells)
bits in RM cell set by switches (“network-assisted”)
NI bit: no increase in rate (mild congestion)
CI bit: congestion indication
ER setting: 2-byte explicit rate field.
RM cells returned to sender by receiver, with bits intact
*ATM is not used on the internet, but it’s an interesting example of how congestion control can be handled.
Transport Layer

18. Case study: ATM* ABR congestion control
two-byte ER (explicit rate) field in RM cell
congested switch may lower ER value in cell
sender’ send rate thus maximum supportable rate on path
EFCI bit in data cells: set to 1 in congested switch
if data cell preceding RM cell has EFCI set, sender sets CI bit in returned RM cell
ATM (asynchronous transfer mode) is a dedicated-connection switching technology that organizes digital data into 53-byte cell units and transmits them over a physical medium using digital signal technology. Individually, a cell is processed asynchronously relative to other related cells and is queued before being multiplexed over the transmission path.
* EFCI: explicit forward congestion indication
* ATM (asynchronous transfer mode) is a dedicated-connection switching technology that organizes digital data into 53-byte cells
Transport Layer

19. Chapter 3 outline 3.1 Transport-layer services
3.2 Multiplexing and demultiplexing
3.3 Connectionless transport: UDP
3.4 Principles of reliable data transfer
3.5 Connection-oriented transport: TCP
segment structure
reliable data transfer
flow control
connection management
3.6 Principles of congestion control
3.7 TCP congestion control
Transport Layer

20. TCP congestion control:
TCP must use end-to-end congestion control; IP will not help!
Each sender limits the rate at which it sends data into its connection as a function of perceived network congestion.
Q: how does TCP limit the rate at which it sends traffic?
Q: how does a TCP sender perceive that there is congestion on the path between itself and the destination?
Q: what algorithm should the sender use to change its send rate as a function of perceived end-to-end congestion?
Transport Layer

21. TCP congestion control:
Q: how does TCP limit the rate at which it sends traffic?
Limiting rate at which it sends traffic
Each side of TCP connection has receive buffer, send buffer, variables (LastByteRead, rwnd, etc.)
TCP congestion control keeps another variable, the congestion window (cwnd):
LastByteSent – LastByteAcked <= min{cwnd,rwnd}
Transport Layer

22. TCP Congestion Control: details
sender sequence number space
TCP sending rate:
roughly: send cwnd bytes, wait RTT for ACKS, then send more bytes
cwnd
last byte
ACKed
last byte sent
sent, not-yet ACKed
(“in-flight”)
sender limits transmission:
cwnd is dynamic, function of perceived network congestion
cwnd
RTT
rate ~
bytes/sec
LastByteSent-
LastByteAcked
<
cwnd
assume receive buffer is so large that rwnd can be ignored.
assume that sender always has data to send
assume loss and packet delays are negligible
Transport Layer

23. TCP Congestion Control: details
sender limits rate by limiting number of unACKed bytes “in pipeline”:
cwnd: differs from rwnd (how, why?)
cwnd: congestion window in bytes
sender limited by min(cwnd,rwnd)
cwnd
bytes
ACK(s)
LastByteSent-LastByteAcked  cwnd
RTT
Transport Layer

24. TCP congestion control:
2. Q: how does a TCP sender perceive that there is congestion on the path between itself and the destination?
ACK: segment received (a good thing!), network not congested, so increase sending rate
lost segment: assume loss due to congested network, so decrease sending rate
goal: TCP sender should transmit as fast as possible, but without congesting network
Q: how to find rate just below congestion level
decentralized: each TCP sender sets its own rate, based on implicit feedback:
Transport Layer

25. TCP: congestion avoidance
AIMD
ACKs: increase cwnd by 1 MSS per RTT: additive increase
loss: cut cwnd in half (non-timeout-detected loss ): multiplicative decrease
AIMD: Additive Increase
Multiplicative Decrease
Transport Layer

26. TCP congestion control: additive increase multiplicative decrease
approach: sender increases transmission rate (window size), probing for usable bandwidth, until loss occurs
additive increase: increase cwnd by 1 MSS (Max Segment Size) every RTT until loss detected
multiplicative decrease: cut cwnd in half after loss
additively increase window size …
…. until loss occurs (then cut window in half)
AIMD saw tooth
behavior: probing
for bandwidth
congestion window size
cwnd: TCP sender
time
Note that the actual curve is more complicated
Transport Layer

27. TCP congestion control:
TCP congestion-control algorithm
Slow start (required in TCP)
Congestion avoidance (required in TCP)
Fast recovery (recommended in TCP)
Transport Layer

28. TCP Congestion Control: overview
segment loss event: reducing cwnd
timeout: no response from receiver
cut cwnd to 1 MSS
3 duplicate ACKs: (some segments getting through)
cut cwnd in half
ACK received: increase cwnd
slowstart phase:
increase exponentially fast at connection start, or following timeout
congestion avoidance:
increase exponentially to threshold
then increase linearly
Transport Layer

29. TCP Slow Start when connection begins, cwnd = 1 MSS (max segment size)
cwnd becomes 2 MSS
when connection begins, cwnd = 1 MSS (max segment size)
example: MSS = 500 bytes & RTT = 200 msec
initial rate = 25 kbps
available bandwidth may be >> MSS/RTT
quickly ramp up to respectable rate
Host A
Host B
one segment
RTT
cwnd = 3 MSS
two segments
four segments
Authors had initial rate = 20 kbps. But the division gives 25 kbps
cwnd = 4 MSS
time
Transport Layer

30. TCP Slow Start
cwnd becomes 2 MSS
increase rate exponentially until first loss event or when threshold reached
double cwnd every RTT
done by incrementing cwnd by 1 for every ACK received
Example:
1 MSS sent
Rcv 1 ACK, so increase cwnd to 2MSS (double)
Now 2 MSS sent
Rcv 2 ACK, incr cwnd by 1 for each to 4 MSS (double)
Now 4 MSS sent
Rcv 4 ACK, incr cwnd by 4 to 8 MSS (double)
Host A
Host B
one segment
RTT
cwnd = 3 MSS
two segments
four segments
Authors had initial rate = 20 kbps. But the division gives 25 kbps
cwnd = 4 MSS
time
Transport Layer

31. Transitioning into/out of slowstart
ssthresh: cwnd threshold variable maintained by TCP
on loss event: set ssthresh to cwnd/2
remember (half of) TCP rate when congestion last occurred
when cwnd >= ssthresh: transition from slowstart to congestion avoidance phase
Transport Layer

32. TCP: congestion avoidance
Goal: incr cwnd slower to avoid congestion
while cwnd <= ssthresh
grow cwnd exponentially:
increase cwnd by 1 MSS per ACK
while cwnd > ssthresh
grow cwnd linearly: cwnd = cwnd + MSS/cwnd per ACK
Transport Layer

33. TCP: congestion avoidance
while cwnd > ssthresh grow cwnd linearly: cwnd = cwnd + (MSS/cwnd per ACK)
Assume cwnd starts at 1MSS
Send one MSS
Recv Ack, cwnd = 1MSS + 1MSS/1MSS or by 1
cwnd now is 2MSS. Send 2MSS
Recv 2 Ack. cwnd = 2MSS + (1MSS/2MSS * 2 ACKs) = 3MSS.
cwnd now is 3MSS. Send 3MSS.
Recv 3 Ack. cwnd = 3MSS + (1MSS/3MSS * 3) = 4MSS.
Result: cwnd grows by 1MSS each RTT
Transport Layer

34. Relation between slowstart and congestion avoidence
dupACKcount++
duplicate ACK
cwnd = cwnd+MSS
dupACKcount = 0
transmit new segment(s),as allowed
new ACK L
cwnd = 1 MSS
ssthresh = 64 KB
dupACKcount = 0
slow
start
congestion
avoidance
cwnd > ssthresh L
timeout
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
timeout
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
Transport Layer

35. TCP: fast recovery
Goal: incr cwnd faster to get back to max transmission rate
increase by 1 MSS per duplicate ACK recieved for the missing segment
when ACK arrives for missing segment, enter congestion-avoidance state after deflating cwnd
if timeout occurs, go to slow-start state after setting ssthresh to ½ cwnd and then cwnd to 1 MSS
Transport Layer

36. TCP congestion control FSM: overview
slow
start
congestion
avoidance
cwnd > ssthresh
loss:
timeout
loss:
timeout
loss:
timeout
new ACK
loss:
3dupACK
fast
recovery
loss:
3dupACK
Transport Layer

37. Summary: TCP Congestion Control
New
ACK!
congestion
avoidance
cwnd = cwnd + MSS (MSS/cwnd)
dupACKcount = 0
transmit new segment(s), as allowed
new ACK .
dupACKcount++
duplicate ACK
slow
start
timeout
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
cwnd = cwnd+MSS
transmit new segment(s), as allowed
new ACK
dupACKcount++
duplicate ACK L
ssthresh = 64 KB L
cwnd > ssthresh
timeout
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
ssthresh= cwnd/2
cwnd = ssthresh + 3
retransmit missing segment
dupACKcount == 3
timeout
ssthresh = cwnd/2
cwnd = 1
dupACKcount = 0
cwnd = ssthresh
dupACKcount = 0
New ACK
ssthresh= cwnd/2
cwnd = ssthresh + 3
retransmit missing segment
dupACKcount == 3
fast
recovery
cwnd = cwnd + MSS
transmit new segment(s), as allowed
duplicate ACK
Transport Layer

38. TCP: detecting, reacting to loss Tahoe vs RENO (newer version)
loss indicated by timeout:
cwnd set to 1 MSS;
window then grows exponentially (as in slow start) to threshold, then grows linearly
loss indicated by 3 duplicate ACKs: TCP RENO
dup ACKs indicate network capable of delivering some segments
cwnd is cut in half window then grows linearly
TCP Tahoe always sets cwnd to 1 (timeout or 3 duplicate acks)
Transport Layer

39. Popular “flavors” of TCP
TCP Reno
ssthresh
cwnd window size (in segments)
ssthresh
TCP Tahoe
Transmission round*
1 Transmission round = send cwnd bytes, receive all ACKs for those bytes (or loss occurs)
Transport Layer

40. Summary: TCP Congestion Control
when cwnd < ssthresh, sender in slow-start phase, window grows exponentially.
when cwnd >= ssthresh, sender is in congestion- avoidance phase, window grows linearly.
when triple duplicate ACK occurs, ssthresh set to cwnd/2, cwnd set to ~ ssthresh
when timeout occurs, ssthresh set to cwnd/2, cwnd set to 1 MSS.
Transport Layer

41. *W is just another symbol for cwnd
TCP throughput
Q: what’s average throughout of TCP as function of window size, RTT?
ignoring slow start
let W* be window size when loss occurs.
when window is W, throughput is W/RTT
just after loss, window drops to W/2, throughput to W/2RTT.
average throughout: .75 W/RTT
*W is just another symbol for cwnd
Transport Layer

42. TCP throughput
Problem: TCP was designed for the days of SMTP, FTP, and Telnet.
Not designed for HTTP-dominated internet and video-on-demand
high-speed TCP connections necessary for grid- and cloud-computing applications require different configurations
Transport Layer

43. TCP Futures: TCP over “long, fat pipes”
example: 1500 byte segments, 100ms RTT, want 10 Gbps throughput
if W is the window size, then throughput is W/RTT so
num segments *1500 * 8 bits/100 x 10-3 sec = 10Gbps
num segments * 120,000 = 10Gbps
num segments = 10 x 109 / 120 x 103
num segments = x 106
requires 83,333 in-flight segments
Transport Layer

44. TCP Futures: TCP over “long, fat pipes”
83,333 in-flight segments is large. Segments will be lost.
throughput can be stated in terms of loss rate (see problem P45):
to get 10Gbps throughput ➜ L = 2· Wow
new versions of TCP for high-speed
Transport Layer

45. TCP Fairness
fairness goal: if K TCP sessions share same bottleneck link of bandwidth R, each should have average rate of R/K
TCP connection 1
bottleneck
router
capacity R
TCP
connection 2
Transport Layer

46. Why is TCP fair? Two competing sessions:
Additive increase gives slope of 1, as throughout increases
multiplicative decrease decreases throughput proportionally R
equal bandwidth share
loss: decrease window by factor of 2
congestion avoidance: additive increase
Connection 2 throughput
loss: decrease window by factor of 2
congestion avoidance: additive increase
Connection 1 throughput R
Transport Layer

47. Fairness (more) Fairness and parallel TCP connections Fairness and UDP
nothing prevents app from opening parallel connections between 2 hosts.
web browsers do this
example: link of rate R supporting 9 connections;
new app asks for 1 TCP, gets rate R/10
new app asks for 11 TCPs, gets R/2 !
Fairness and UDP
multimedia apps often do not use TCP
do not want rate throttled by congestion control
instead use UDP:
pump audio/video at constant rate, tolerate packet loss
Transport Layer

48. Chapter 3: Summary principles behind transport layer services:
multiplexing, demultiplexing
reliable data transfer
flow control
congestion control
instantiation and implementation in the Internet
UDP
TCP
Next:
leaving the network “edge” (application, transport layers)
into the network “core”
Transport Layer