cs/ee 143 Communication Networks

Chapter 4 Transport
Text: Walrand & Parakh, 2010
Steven Low
CMS, EE, Caltech

This week
Internetworking
Routing across LANs, layer2-layer3
DHCP
NAT

Transport layer
Connection setup
Error recovery: retransmission
Congestion control

Protocol stack
Network mechanisms implemented as
protocol stack
Each layer designed separately, evolves
asynchronously
application

Many control mechanisms

transport

Error control, congestion control (TCP)

network

Routing (IP)

link

Medium access control

physical

Coding, transmission, synchronization

Transport services

UDP
Datagram service
No congestion control
No error/loss recovery
Lightweight

TCP
Connection oriented service
Congestion control
Error/loss recovery
Heavyweight

UDP
1 ~ 65535 (216-1)

UDP header
65535 Bytes 8 Bytes (UDP header) 20 Bytes (IP header)
Usually smaller to avoid IP fragmentation (e.g., Ethernet MTU 1500 Bytes)

TCP

TCP header

Example TCP states

3-way handshake

4-way handshake

Possible issue: SYN flood attack

Result in large numbers of half-open connections and no new
connections can be made.

Window Flow Control

RTT
Source

1 2

time

ACKs

data
Destination

1 2

1 2

1 2

time

~ W packets per RTT

Lost packet detected by missing ACK

ARQ (Automatic Repeat Request)

Go-back-N

Selective repeat

TCP
Sender & receiver negotiate whether
or
not to use Selective Repeat (SACK)
Can ack up to 4 blocks of contiguous
bytes that receiver got correctly

Window control
Limit the number of packets in the
network to window W

W MSS
Source rate =
bps
RTT
If W too small then rate capacity
If W too big then rate > capacity
=> congestion

Adapt W to network (and conditions)

TCP window control

Receiver flow control
Avoid overloading receiver
Set by receiver
awnd: receiver (advertised) window

Network congestion control

Avoid overloading network

Set by sender
Infer available network capacity
cwnd: congestion window

Set W = min (cwnd, awnd)

TCP congestion control

Source calculates cwnd from indication of
network congestion
Congestion indications
Losses
Delay
Marks

Algorithms to calculate cwnd

Tahoe, Reno, Vegas,

TCP Congestion Controls

Tahoe (Jacobson 1988)
Slow Start
Congestion Avoidance
Fast Retransmit

Reno (Jacobson 1990)

Fast Recovery

Vegas (Brakmo & Peterson 1994)

New Congestion Avoidance

TCP Tahoe

(Jacobson 1988)

window

time
SS

CA
: Slow Start
: Congestion Avoidance
: Threshold

Slow Start
Start with cwnd = 1 (slow start)
On each successful ACK increment cwnd
cwnd cnwd + 1
Exponential growth of cwnd
each RTT: cwnd 2 x cwnd
Enter CA when cwnd >= ssthresh

Congestion Avoidance
Starts when cwnd ssthresh
On each successful ACK:
cwnd
cwnd + 1/cwnd
Linear growth of cwnd
each RTT: cwnd cwnd + 1

Packet Loss
Assumption: loss indicates congestion
Packet loss detected by
Retransmission TimeOuts (RTO timer)
Duplicate ACKs (at least 3) (Fast Retransmit)
Packets

Acknowledgements

Fast Retransmit
Wait for a timeout is quite long
Immediately retransmits after 3 dupACKs
without waiting for timeout
Adjusts ssthresh
flightsize = min(awnd, cwnd)
ssthresh max(flightsize/2, 2)
Enter Slow Start (cwnd = 1)

Summary: Tahoe
Basic ideas
Gently probe network for spare capacity
Drastically reduce rate on congestion
Windowing: self-clocking

for every ACK {

if (W < ssthresh) then W++
(SS)
else
W += 1/W
(CA)
}
for every loss {
ssthresh = W/2
W = 1
}
Seems a little too conservative?

TCP Reno

(Jacobson 1990)

SS

CA

for every ACK {

W += 1/W
}
for every loss {
W = W/2
}

(AI)
(MD)

How to halve W without emptying the pipe?

Fast Recovery

Fast recovery
Idea: each dupACK represents a packet
having left the pipe (successfully
received)
Enter FR/FR after 3 dupACKs
Set ssthresh max(flightsize/2, 2)
Retransmit lost packet
Set cwnd ssthresh + ndup (window
inflation)
Wait till W=min(awnd, cwnd) is large
enough; transmit new packet(s)
On non-dup ACK, set cwnd ssthresh
(window deflation)

Enter CA

Example: FR/FR
S 1 2 3 4 5 6 7 8

9 10 11

time
Exit FR/FR

0 0 0 0 0 0 0

cwnd
8
ssthresh

7
4

time

8
9
4

11
4

4
4

Fast retransmit
Retransmit on 3 dupACKs

Fast recovery
Inflate window while repairing loss to fill pipe

Summary: Reno
Basic ideas
dupACKs: halve W and avoid slow start
dupACKs: fast retransmit + fast recovery
Timeout: slow start

dupACKs
congestion
avoidance

FR/FR
timeout

slow start

retransmit

Multiple loss in Reno?

FR/FR

S 1 2 3 4 5 6 7 8 9 0
D

1
0

0
8

2
9

time
time

timeout

8 unackd pkts

On 3 dupACKs, receiver has packets 2, 4, 6, 8,

cwnd=8, retransmits pkt 1, enter FR/FR
Next dupACK increment cwnd to 9
After a RTT, ACK arrives for pkts 1 & 2, exit
FR/FR, cwnd=5, 8 unacked pkts
No more ACK, sender must wait for timeout

New Reno

Fall & Floyd 96, (RFC 2583)

Motivation: multiple losses within a window

Partial ACK takes Reno out of FR, deflates
window
Sender may have to wait for timeout before
proceeding

Idea: partial ACK indicates lost packets

Stays in FR/FR and retransmits immediately
Retransmits 1 lost packet per RTT until all lost
packets from that window are retransmitted
Eliminates timeout

Model: Reno
f or
{
f or
{

ever y ack ( ca)

W += 1/ W }
ever y l oss
W : = W/ 2
}

x i ( t ) (1 q i ( t ) )
wi

w i(t)
xi(t)qi(t)
2

Model: Reno
f or
{
f or
{

ever y ack ( ca)

W += 1/ W }
ever y l oss
W : = W/ 2
}

throughput

x i ( t ) (1 q i ( t ) )
w i(t)

window size

w i(t)
xi(t)qi(t)
2

qi(t)

round-trip
loss probability

R li p l ( t )
l

link loss
probability

Model: Reno
f or
{
f or
{

ever y ack ( ca)

W += 1/ W }
ever y l oss
W : = W/ 2
}

x i ( t ) (1 q i ( t ) )
w i(t)

xi
xx
1) 2
qi(t)
i ( t i (t)
Ti
2
! ## " # #$
1

Steady state:

F i x i ( t2
),qi ( t)

xi

Ti qi

Fair? Unfair?

w i(t)
xi(t)qi(t)
2
U ses:
w i(t)
xi(t)
Ti
qi(t) 0

Delay-based TCP: Vegas

(Brakmo & Peterson 1994)
window

time
SS

CA

Reno with a new congestion avoidance

algorithm
Converges (provided buffer is large) !

Congestion avoidance
Each source estimates number of its own
packets in pipe from RTT
Adjusts window to maintain estimate #
of packets in queues between and
for every RTT
{
if W/RTTmin W/RTT < RTTmin then W ++
if W/RTTmin W/RTT > RTTminthen W -}
for every loss
W := W/2

Implications
Congestion measure = end-to-end
queueing delay
At equilibrium
Zero loss
Stable window at full utilization
Nonzero queue, larger for more sources

Convergence to equilibrium
Converges if sufficient network buffer
Oscillates like Reno otherwise

Theory-guided design: FAST

We will study them further in TCP modeling in the following

weeks
A simple model of AIMD (Reno) for example

Summary
UDP header/TCP header
TCP 3-way/4-way handshake
ARQ: Go-back-N/selective repeat
Tahoe/Reno/New Reno/Vegas/FAST
-- useful details for your project
Simply model of AIMD

Why both TCP and UDP?

Most applications use TCP, as this avoids
re-inventing error recovery in every
application
But some applications do not need TCP
For example: Voice applications
Some packet loss is fine.
Packet retransmission introduces too much
delay.
For example: an application that sends just
one message, like DNS/SNMP/RIP.
TCP sends several packets before the useful
one.
We may add reliability at application layer

40