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.