Chapter 3 outline

 3.1 Transport-layer  3.5 Connection-oriented

services transport: TCP
 3.2 Multiplexing and  segment structure
demultiplexing  reliable data transfer
 3.3 Connectionless
 flow control
connection management
transport: UDP


 3.6 Principles of
 3.4 Principles of
reliable data transfer congestion control
 3.7 TCP congestion
control

Transport Layer 3-1

Principles of Congestion Control

Congestion:
 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 3-2

 Causes/costs of congestion: scenario 1
Host A
out
 two senders, two in : original data

receivers
unlimited shared
 one router,
Host B
output link buffers

infinite buffers
 no retransmission

R/2  large delays

when congested
delay

 maximum
out

achievable
in R/2 in R/2
throughput
Transport Layer 3-3
 Causes/costs of congestion: scenario 2
 one router,finite buffers
 sender retransmission of lost packet

Host A
in : original data out

'in : original data, plus

retransmitted data

Host B finite shared output link

buffers

Transport Layer 3-4

 Causes/costs of congestion: scenario 2
a. always: =  (goodput)
in out
b. “perfect” retransmission only when loss: > 
in out
c. retransmission of delayed (not lost) packet makes in larger
(than perfect case) for same 
out
R/2 R/2 R/2

R/3
out

out
out

R/4

R/2 R/2 R/2

in in in

a. b. c.
“costs” of congestion:
 more work (retrans) for given “goodput”
 unneeded retransmissions: link carries multiple copies of pkt

Transport Layer 3-5

Causes/costs of congestion: scenario 3
 four senders
Q: what happens as 
 multihop paths in
and  increase ?
 timeout/retransmit in
Host A out
in : original data
'in : original data, plus
retransmitted data

finite shared output link buffers

Host B

Transport Layer 3-6

Causes/costs of congestion: scenario 3
Host A o
ut

Host B

Another “cost” of congestion:

 when packet dropped, any “upstream transmission capacity used
for that packet was wasted!

Transport Layer 3-7

Approaches towards congestion control
Two broad approaches towards congestion control:

End-end congestion Network-assisted

control: congestion control:
 no explicit feedback from  routers provide feedback
network to end systems
 congestion inferred from  single bit indicating
end-system observed loss, congestion (SNA,
delay DECbit, TCP/IP ECN,
 approach taken by TCP ATM)
 explicit rate sender
should send at

Transport Layer 3-8

Chapter 3 outline
 3.1 Transport-layer  3.5 Connection-oriented
services transport: TCP
 3.2 Multiplexing and  segment structure
demultiplexing  reliable data transfer
 3.3 Connectionless
 flow control
connection management
transport: UDP


 3.6 Principles of
 3.4 Principles of
reliable data transfer congestion control
 3.7 TCP congestion
control

Transport Layer 3-9

 TCP congestion control: additive increase,
multiplicative decrease
 Approach: increase transmission rate (window size), probing for usable
bandwidth, until loss occurs
 additive increase: increase CongWin by 1 MSS every RTT until loss detected
 multiplicative decrease : cut CongWin in half after loss

c o n g e s tio n
w in d o w
congestion window size

2 4 K b y te s

Saw tooth
behavior: probing
1 6 K b y te s

for bandwidth
8 K b y te s

time
tim e

Transport Layer 3-10

 TCP Congestion Control: details
sender sequence number space
cwnd How does sender
perceive congestion?
 loss event = timeout or
last byte last byte
3 duplicate acks
sent, not-yet sent
ACKed
ACKed  TCP sender reduces
(“in-flight”)
rate (CongWin) after
 sender limits transmission:
loss event
LastByteSent-LastByteAcked
 CongWin
three mechanisms:
 AIMD
 Roughly,
 slow start
CongWin
rate = Bytes/sec  conservative after
RTT timeout events
 CongWin is dynamic, function
of perceived network congestn. Transport Layer 3-11
 TCP Slow Start
 When connection begins,  When connection begins,
CongWin = 1 MSS increase rate
 Example: MSS = 500 exponentially fast until
bytes & RTT = 200 msec first loss event
 initial rate = 20 kbps
 available bandwidth may
be >> MSS/RTT
 desirable to quickly ramp
up to respectable rate

Transport Layer 3-12

TCP Slow Start (more)
 When connection Host A Host B
begins, increase rate
exponentially until
one segm
ent

RTT
first loss event:
two segm
 double CongWin every ents
RTT
 done by incrementing
CongWin for every ACK four segm
ents
received
 Summary: initial rate
is slow but ramps up
exponentially fast time

Transport Layer 3-13

 Refinement: inferring loss
 After 3 dup ACKs:
 CongWin is cut in half
 window then grows linearly Philosophy:
 But after timeout event:
 CongWin instead set to 1 MSS;  3 dup ACKs indicates
 window then grows exponentially
network capable of
 to a threshold, then grows linearly
delivering some segments
 timeout indicates a
“more alarming”
congestion scenario

Transport Layer 3-14

Refinement
Q: When should the
exponential increase
switch to linear?
A: When CongWin gets
to 1/2 of its value
before timeout.

Implementation:
 Variable Threshold (ssthresh)
 At loss event, Threshold is set
to 1/2 of CongWin just before
loss event

Transport Layer 3-15

Summary: TCP Congestion Control

 When CongWin is below Threshold, sender in

slow-start phase, window grows exponentially.
 When CongWin is above Threshold, sender is in
congestion-avoidance phase, window grows linearly.
 When a triple duplicate ACK occurs, Threshold
set to CongWin/2 and CongWin set to
Threshold.
 When timeout occurs, Threshold set to
CongWin/2 and CongWin is set to 1 MSS.

Transport Layer 3-16

TCP sender congestion control
State Event TCP Sender Action Commentary
Slow Start ACK receipt CongWin = CongWin + MSS, Resulting in a doubling of
(SS) for previously If (CongWin > Threshold) CongWin every RTT
unacked set state to “Congestion
data Avoidance”
Congestion ACK receipt CongWin = CongWin+MSS * Additive increase, resulting
Avoidance for previously (MSS/CongWin) in increase of CongWin by
(CA) unacked 1 MSS every RTT
data
SS or CA Loss event Threshold = CongWin/2, Fast recovery,
detected by CongWin = Threshold, implementing multiplicative
triple Set state to “Congestion decrease. CongWin will not
duplicate Avoidance” drop below 1 MSS.
ACK

SS or CA Timeout Threshold = CongWin/2, Enter slow start

CongWin = 1 MSS,
Set state to “Slow Start”
SS or CA Duplicate Increment duplicate ACK count CongWin and Threshold
ACK for segment being acked not changed

Transport Layer 3-17

TCP throughput
 What’s the average throughout of TCP as a
function of window size and RTT?
 Ignore slow start
 Let W be the 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

Transport Layer 3-18

TCP Futures: TCP over “long, fat pipes”

 Example: 1500 byte segments, 100ms RTT, want 10

Gbps throughput
 Requires window size W = 83,333 in-flight
segments
 Throughput in terms of loss rate:

1.22  MSS
RTT L
Wow
 ➜ L = 2·10-10
 New versions of TCP for high-speed

Transport Layer 3-19

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
TCP
router
connection 2
capacity R

Transport Layer 3-20

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

Connection 2 throughput

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 R

Transport Layer 3-21

Fairness (more)
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
 Research area: TCP
friendly
Fairness and parallel TCP
connections
 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 !
Transport Layer 3-22
Chapter 3: Summary
 principles behind transport
layer services:
 multiplexing, demultiplexing
 reliable data transfer
 flow control
 congestion control
 instantiation and Next:
implementation in the Internet  leaving the network
 UDP “edge” (application,
 TCP transport layers)
 into the network
“core”

Transport Layer 3-23