Upload
toni-goy
View
222
Download
0
Embed Size (px)
Citation preview
cs/ee 143 Communication Networks
Chapter 7 Transport
Text: Walrand & Parakh, 2010
Steven LowCMS, EE, Caltech
This week
Internetworking Routing across LANs, layer2-layer3 DHCP NAT
Transport layer Connection setup Error recovery: retransmission Congestion control
Transport services
UDP• Datagram service• No congestion control• No error/loss recovery• Lightweight
TCP • Connection oriented service• Congestion control• Error/loss recovery• Heavyweight
UDP
UDP header
1 ~ 65535 (216-1)
≤ 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 attackResult in large numbers of half-open connections and no new
connections can be made.
Window Flow Control
~ W packets per RTT Lost packet detected by missing ACK
RTT
time
time
Source
Destination
1 2 W
1 2 W
1 2 W
data ACKs
1 2 W
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
Source rate = bps
If W too small then rate « capacityIf W too big then rate > capacity
=> congestion
Adapt W to network (and conditions)
RTT
MSSW
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)
SStime
window
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)
1 2 3 4 5 6
1 2 3
Packets
Acknowledgements
3 3
7
3
(Fast Retransmit)
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)
CASS
for every ACK { W += 1/W (AI)}for every loss {
W = W/2 (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
9
94
0 0
Example: FR/FR
Fast retransmit Retransmit on 3 dupACKs
Fast recovery Inflate window while repairing loss to fill pipe
timeS
timeR
1 2 3 4 5 6 87
8
cwnd 8ssthresh
1
74
0 0 0
Exit FR/FR
44
411
00
10 11
Summary: Reno
Basic ideas dupACKs: halve W and avoid slow start dupACKs: fast retransmit + fast recovery Timeout: slow start
slow start retransmit
congestion avoidance FR/FR
dupACKs
timeout
Multiple loss in Reno?
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
1 2timeS
timeD
3 4 5 6 87 1
8
FR/FR
09
0 0 0 0 0
9
8 unack’d pkts
2
5
3
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
Steady state: Fair? Unfair?
Delay-based TCP: Vegas (Brakmo & Peterson 1994)
Reno with a new congestion avoidance algorithm
Converges (provided buffer is large) !
SStime
window
CA
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
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
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
40
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 instead.