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
