CIS3210 – Computer Networks
Transport Layer – Congestion Control
1
Jason Ernst, University of Guelph - Fall 2011
Housekeeping

A1 Questions?

Breakdown of A1 Marking Scheme posted on website

Recall Last class:


2
Flow control, Connection & Congestion Managmement
http://media.pearsoncmg.com/aw/aw_kurose_network_2/apple
ts/flow/flowcontrol.html
Jason Ernst, University of Guelph - Fall 2011
Sample Problem: RDT 3.0

3
Suppose an application uses rdt3.0 as its transport layer
protocol. As the stop-and-wait has very low channel
utilization, the designer of the application let the receiver
keep sending back a number (more than 2) of alternating
ACK0 and ACK1 even if the corresponding data have not
arrived at the receiver. Would this design increase the
channel utilization? Are there problems with the design?
Jason Ernst, University of Guelph - Fall 2011
Sample Problem RDT 3.0
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
L
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,1)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,0) )
4
timeout
udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
stop_timer
stop_timer
timeout
udt_send(sndpkt)
start_timer
L
Wait
for
ACK0
Wait for
call 0from
above
L
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
Wait
for
ACK1
Wait for
call 1 from
above
rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
start_timer
Jason Ernst, University of Guelph - Fall 2011
rdt_rcv(rcvpkt)
L
Sample Problem: RDT 3.0

Would this design increase the channel utilization?


5
Yes. This actually causes the sender to send a number of pipelined
data into the channel.
Are there problems with the design?

Yes. Here is one potential problem. If data segments are lost in
the channel (not corrupt), then the sender of rdt 3.0 won’t resend those segments, unless there are some additional mechanism
in the application to recover from loss.

Since there is only 1 or 0 for seq # and more than 2 packets are
in network at all times, impossible to determine which has been
lost
Jason Ernst, University of Guelph - Fall 2011
Outline
Transport Layer Services
Multiplexing / De-multiplexing
Connectionless Transport: UDP
Principles of Reliable Data Transfer
Connection Oriented Transport: TCP









Segment Structure
Reliable Data Transfer
Flow Control
Connection Management
Principles of Congestion Control
TCP Congestion Control


6
Jason Ernst, University of Guelph - Fall 2011
Principles of Congestion Control
Congestion:


informally: “too many sources sending too much data too
fast for network to handle”
different from flow control!



7
Recall what is flow control?
manifestations:
 lost packets (buffer overflow at routers)
 long delays (queuing in router buffers)
a top-10 problem!
Jason Ernst, University of Guelph - Fall 2011
Causes / Costs of Congestion: Scenario 1



two senders, two
receivers
one router, infinite
buffers
no retransmission
Host A
Host B
lout
lin : original data
unlimited shared
output link buffers


8
Jason Ernst, University of Guelph - Fall 2011
large delays when
congested
maximum
achievable
throughput
Causes / Costs of Congestion: Scenario 1



two senders, two
receivers
one router, infinite
buffers
no retransmission
Host A
Host B
lout
lin : original data
unlimited shared
output link buffers


9
Jason Ernst, University of Guelph - Fall 2011
Rate in and Rate
out grow until
capacity is hit
As capacity is
reached, infinite
waiting (no drops)
Causes / Costs of Congestion: Scenario 2


one router, finite buffers
sender retransmission of lost packet
Host A
Host B
10
lin : original
data
l'in : original data, plus
retransmitted data
finite shared output
link buffers
Jason Ernst, University of Guelph - Fall 2011
lout
Causes / Costs of Congestion: Scenario 2
 always: l = l
out (goodput)
in
 “perfect” retransmission only when loss: l > lout
in
 retransmission of delayed (not lost) packet makes l larger (than perfect
in
case) for same lout
R/2
R/2
R/2
lin
a.
R/2
lout
lout
lout
R/3
lin
R/4
R/2
b.
lin
c.
“costs” of congestion:
 more work (retrans) for given “goodput”
 unneeded retransmissions: link carries multiple copies of pkt
11
Jason Ernst, University of Guelph - Fall 2011
R/2
Causes / Costs of Congestion: Scenario 3



Q: what happens as lin
and l increase ?
four senders
multihop paths
timeout/retransmit
in
Host A
lin : original data
l'in : original data, plus
retransmitted data
finite shared output
link buffers
Host B
12
Jason Ernst, University of Guelph - Fall 2011
lout
Causes / Costs of Congestion: Scenario 3



four senders
multihop paths
timeout/retransmit
What happens if (green) packet loss here?
Host A
lin : original data
l'in : original data, plus
retransmitted data
finite shared output
link buffers
Host B
13
Jason Ernst, University of Guelph - Fall 2011
lout
Causes / Costs of Congestion: Scenario 3



four senders
multihop paths
timeout/retransmit
Also causes increased congestion at previous
hop on retransmissions
Host A
lin : original data
l'in : original data, plus
retransmitted data
finite shared output
link buffers
Host B
14
Jason Ernst, University of Guelph - Fall 2011
lout
Causes / Costs of Congestion: Scenario 3
H
o
s
t
A
l
o
u
t
H
o
s
t
B
another “cost” of congestion:
 when packet dropped, any “upstream transmission capacity
used for that packet was wasted!
15
Jason Ernst, University of Guelph - Fall 2011
Two Approaches Towards Congestion
Control
two broad approaches towards congestion control:
end-end congestion control: network-assisted congestion
control:
 no explicit feedback from


16
network
congestion inferred from endsystem observed loss, delay
approach taken by TCP

routers provide feedback to end
systems
 single bit indicating
congestion (SNA, DECbit,
TCP/IP ECN, ATM)
 explicit rate sender should
send at
Jason Ernst, University of Guelph - Fall 2011
Two Approaches Towards Congestion
Control
Inferred by loss & delay
Congestion bits
17
Jason Ernst, University of Guelph - Fall 2011
Two Approaches Towards Congestion
Control

End-to-end VS Network Assisted

Network assisted provides finer grain feedback on where the
congestion is occurring



End-to-end


18
Requires trust of the routers involved
Possible for manipulation of traffic
Loss may be inferred as congestion (which was acceptable in wired
networks)
In wireless, loss may be due to interference
Jason Ernst, University of Guelph - Fall 2011
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:



19
sent by sender, interspersed with
data cells
bits in RM cell set by switches
(“network-assisted”)
 NI bit: no increase in rate (mild
congestion)
 CI bit: congestion indication
RM cells returned to sender by
receiver, with bits intact
Jason Ernst, University of Guelph - Fall 2011
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

20
if data cell preceding RM cell has EFCI set, sender sets CI bit in
returned RM cell
Jason Ernst, University of Guelph - Fall 2011
Outline





Transport Layer Services
Multiplexing / De-multiplexing
Connectionless Transport: UDP
Principles of Reliable Data Transfer
Connection Oriented Transport: TCP






Segment Structure
Reliable Data Transfer
Flow Control
Connection Management
Principles of Congestion Control
TCP Congestion Control
21
Jason Ernst, University of Guelph - Fall 2011
TCP Congestion Control
 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:
 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
22
Jason Ernst, University of Guelph - Fall 2011
TCP Congestion Probing: Bandwidth Control
 “probing for bandwidth”: increase transmission rate on receipt
of ACK, until eventually loss occurs, then decrease
transmission rate

continue to increase on ACK, decrease on loss (since available
bandwidth is changing, depending on other connections in network)
sending rate
ACKs being received,
so increase rate
X loss, so decrease rate
X
X
X
TCP’s
“sawtooth”
behavior
X
time
 Q: how fast to increase/decrease?
 details to follow
23
Jason Ernst, University of Guelph - Fall 2011
TCP Congestion Control: Details

sender limits rate by limiting number of
unACKed bytes “in pipeline”:
LastByteSent-LastByteAcked  cwnd



cwnd: differs from rwnd (how, why?)
sender limited by min(cwnd,rwnd)
roughly,
rate =

cwnd
RTT
bytes/sec
cwnd is dynamic, function of perceived
network congestion
cwnd
bytes
RTT
ACK(s)
24
Jason Ernst, University of Guelph - Fall 2011
Difference between cwnd and rwnd

Recall:

rwnd (reciver window) is related to size of receiver buffer
(currently)
application
TCP data
IP
unused buffer
(in buffer) process
datagrams space
rwnd
RcvBuffer
cwnd (congestion window) is related to size
of data being sent at once
cwnd
bytes

RTT
ACK(s)
25
Jason Ernst, University of Guelph - Fall 2011
TCP Congestion Control: More Details
Segment loss event:
reducing cwnd

timeout: no response from
receiver


ACK received:
increase cwnd
cut cwnd to 1
3 duplicate ACKs: at least
some segments getting
through (recall fast
retransmit)

26
 slowstart phase:
 increase exponentially fast
(despite name) at connection
start, or following timeout
 congestion avoidance:
 increase linearly
cut cwnd in half, less
aggressively than on timeout
Jason Ernst, University of Guelph - Fall 2011
TCP Slow Start
when connection begins, cwnd = 1
MSS
 example: MSS = 500 bytes & RTT =
200 msec
 initial rate = 20 kbps

available bandwidth may be >>
MSS/RTT
 desirable to quickly ramp up to
respectable rate

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
27
Host A
Host B
RTT

Jason Ernst, University of Guelph - Fall 2011
time
Transitioning into/out of slowstart
ssthresh: cwnd threshold 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
duplicate ACK
dupACKcount++
L
cwnd = 1 MSS
ssthresh = 64 KB
dupACKcount = 0
slow
start
timeout
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
28
new ACK
cwnd = cwnd+MSS
dupACKcount = 0
transmit new segment(s),as allowed
cwnd > ssthresh
L
timeout
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
Jason Ernst, University of Guelph - Fall 2011
congestion
avoidance
TCP: Congestion Avoidance

29
when cwnd > ssthresh
grow cwnd linearly
 increase cwnd by 1 MSS
per RTT
 approach possible
congestion slower than in
slowstart
 implementation: cwnd =
cwnd + MSS/cwnd for
each ACK received
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
Jason Ernst, University of Guelph - Fall 2011
TCP Congestion Control FSM: Overview
cwnd > ssthresh
slow
start
loss:
timeout
congestion
avoidance
loss:
timeout
loss:
timeout
loss:
3dupACK
30
new ACK
fast
recovery
Jason Ernst, University of Guelph - Fall 2011
loss:
3dupACK
TCP Congestion Control FSM: Details
duplicate ACK
dupACKcount++
L
cwnd = 1 MSS
ssthresh = 64 KB
dupACKcount = 0
slow
start
timeout
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
dupACKcount == 3
ssthresh= cwnd/2
cwnd = ssthresh + 3
retransmit missing segment
new ACK
cwnd = cwnd+MSS
dupACKcount = 0
transmit new segment(s),as allowed
cwnd > ssthresh
L
timeout
ssthresh = cwnd/2
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment
timeout
ssthresh = cwnd/2
cwnd = 1
dupACKcount = 0
retransmit missing segment
new ACK
cwnd = cwnd + MSS (MSS/cwnd)
dupACKcount = 0
transmit new segment(s),as allowed
.
congestion
avoidance
duplicate ACK
dupACKcount++
New ACK
cwnd = ssthresh
dupACKcount = 0
dupACKcount == 3
ssthresh= cwnd/2
cwnd = ssthresh + 3
retransmit missing segment
fast
recovery
duplicate ACK
cwnd = cwnd + MSS
transmit new segment(s), as allowed
31
Jason Ernst, University of Guelph - Fall 2011
Popular “flavours” of TCP
32
Jason Ernst, University of Guelph - Fall 2011
Summary: TCP Congestion Control

when cwnd < ssthresh, sender in slow-start phase,
window grows exponentially.

when cwnd >= ssthresh, sender is in congestionavoidance 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.
33
Jason Ernst, University of Guelph - Fall 2011
TCP Throughput

Q: what’s average throughout of TCP as function of
window size, RTT?

34
ignoring slow start
Jason Ernst, University of Guelph - Fall 2011
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.



35
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
Jason Ernst, University of Guelph - Fall 2011
TCP Future: TCP over “long, fat pipes”




36
example: 1500 byte segments, 100ms RTT, want 10
Gbps throughput
requires window size W = 83,333 in-flight segments
(lots of them!)
What happens in case of a loss ?
And What fraction of segments could be lost and
TCP still achieves the desired rate of 10Gbps?
Jason Ernst, University of Guelph - Fall 2011
TCP Future: TCP over “long, fat pipes”

throughput in terms of loss rate:

➜ L = 2·10-10
new versions of TCP for high-speed

37
Jason Ernst, University of Guelph - Fall 2011
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
TCP
connection 2
38
bottleneck
router
capacity R
Jason Ernst, University of Guelph - Fall 2011
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
loss: decrease window by factor of 2
congestion avoidance: additive increase
Connection 1 throughput
39
R
Jason Ernst, University of Guelph - Fall 2011
Fairness (more)
Fairness and parallel TCP
connections
 nothing prevents app from
opening parallel connections
 do not want rate throttled by
between 2 hosts.
congestion control
 web browsers do this
instead use UDP:
 pump audio/video at constant  example: link of rate R
rate, tolerate packet loss
supporting 9 connections;
Fairness and UDP
 multimedia apps often do
not use TCP



40
new app asks for 1 TCP, gets rate
R/10
new app asks for 11 TCPs, gets R/2
!
Jason Ernst, University of Guelph - Fall 2011
TCP Fairness

Animation:

41
http://media.pearsoncmg.com/aw/aw_kurose_network_4/apple
ts/fairness/index.html
Jason Ernst, University of Guelph - Fall 2011
Sample Problem: TCP Flow Control

42
Hosts A and B are directly connected with a 100Mbps link.
There is one TCP connection between the two hosts. Host
A is sending a very large file to host B over this connection.
Host A sends its application data to its socket at a rate as
high as 120Mbps but Host B can read out of its TCP receive
buffer at a maximum rate of 60Mbps. Describe the effect of
TCP flow control.
Jason Ernst, University of Guelph - Fall 2011
Sample Problem: GBN vs SR vs TCP:

Assume that the timeout period is sufficiently long such that 5
consecutive segments and their ACKs can be received (if not lost
in the channel) by host B and host A respectively. Suppose A
sends 5 segments to B and the 2nd segment from A is lost. In the
end all 5 segments have been received by B.
a)- How many segments has A sent in total and how many ACKs
has B sent in total? What are their sequence numbers?
b)- If the timeout period for all 3 protocols are much longer than
5RTT. Which protocol successfully delivers all 5 segments in
shortest time interval?
43
Jason Ernst, University of Guelph - Fall 2011
Sample Problem: TCP

44
Consider the behavior of TCP Reno as shown in the figure
below.
Jason Ernst, University of Guelph - Fall 2011
Sample Problem: TCP









45
Identify the slow start phase
Identify the intervals when TCP CA is operating
After the 16th transmission round, is segment loss detected by time out
or triple duplicate ACKs?
After the 22nd transmission round, is segment loss detected by a triple
ACKs or timeout?
What is the initial value of ssthresh at the first transmission round?
What is the value of ssthresh at the 18th transmission round?
What is the value of ssthresh at the 24th transmission round?
During what transmission round segment # 70 is sent?
Assume a packet loss is detected after the 26th round by receipt of
triple ACKs. What will the value of congestion window size and ssthresh
?
Jason Ernst, University of Guelph - Fall 2011
Next Class

TCP Variations

TCP Vulnerabilities

RSVP Protocol


Used for QoS
Wrap up of Transport Layer
46
Jason Ernst, University of Guelph - Fall 2011
Reference
 *Computer
,
Networking: A Top Down Approach
5th edition. Jim Kurose, Keith Ross AddisonWesley, April 2009

This set of slide has been modified by Nidal
Nasser, 2010 and Jason Ernst, 2011
47
Jason Ernst, University of Guelph - Fall 2011