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
W
W
time
ACKs
data
Destination
1 2
1 2
W
1 2
W
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
e.g. [3; 10, 14; 16, 20; 25, 33]
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
1
2
3
4
5
7
6
Acknowledgements
1
2
3
3
3
3
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++
else W += 1/W
}
for every loss {
ssthresh = W/2
W = 1
}
(SS)
(CA)
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
1
9 10 11
time
Exit FR/FR
R
cwnd
ssthresh
0 0 0 0 0 0 0
8
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
0
0
0
1
0
3
0
8
2
9
time
time
5
timeout
8 unack’d 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 unack’ed 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
for
{
for
{
every ack ( ca)
W += 1/W
}
every loss
W := W/2
}
! wi ( t )
=
xi (t)(1² qi (t))
wi
²
wi (t)
xi (t)qi (t)
2
Model: Reno
for
{
for
{
every ack ( ca)
W += 1/W
}
every loss
W := W/2
}
! wi ( t )
=
throughput
xi (t)(1² qi (t))
wi (t)
window size
²
wi (t)
xi (t)qi (t)
2
qi (t) = ! Rli pl (t)
l
round-trip
loss probability
link loss
probability
Model: Reno
for
{
for
{
every ack ( ca)
W += 1/W
}
every loss
W := W/2
}
! wi ( t )
xi (t)(1² qi (t))
wi (t)
=
²
1 x
xDx
+1) = 2 !
qi (t)
i (ti (t)
Ti
2
! ## " # #$
2
i
Steady state:
Fi ( xi (t2
),qi (t ))
xi »
Ti qi
Fair? Unfair?
wi (t)
xi (t)qi (t)
2
Uses:
wi (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 a and b
for every RTT
{
if W/RTTmin – W/RTT < a / RTTmin
then W ++
if W/RTTmin – W/RTT > b / RTTmin
then 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 reinventing 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 instead.