Title: TCP and UDP CS 352 Dept. of Computer Science Rutgers University
1TCP and UDPCS 352 Dept. of Computer
ScienceRutgers University
2The Internet Transport Layer
- The Internet supports two transport layer
protocols - The Transport Control Protocol (TCP) for reliable
service - The Unreliable Datagram Protocol (UDP)
3 UDP
- UDP is an unreliable transport protocol that can
be used in the Internet - UDP does not provide
- flow or error control
- connection management
- guaranteed in-order packet delivery
- UDP is almost a null transport layer
4UDP Frame Format
32 bits
Source Port
Destination Port
UDP length
UDP checksum (optional)
Data
5Why UDP?
- No connection needs to be set up
- Throughput may be higher because UDP packets are
easier to process, especially at the source - The user doesnt care if the data is transmitted
reliably - The user wants to implement his or her own
transport protocol
6UDP checksum
- Goal detect errors (e.g., flipped bits) in
transmitted segment
- Sender
- treat segment contents as sequence of 16-bit
integers - checksum addition (1s complement sum) of
segment contents - sender puts checksum value into UDP checksum
field
- Receiver
- compute checksum of received segment
- check if computed checksum equals checksum field
value - NO - error detected
- YES - no error detected. But maybe errors
nonetheless? More later .
7Internet Checksum Example
- Note
- When adding numbers, a carryout from the most
significant bit needs to be added to the result - Example add two 16-bit integers
1 1 1 1 0 0 1 1 0 0 1 1 0 0 1 1
0 1 1 1 0 1 0 1 0 1 0 1 0 1 0 1 0
1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1
1 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1
0 0 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0
1 1
Wraparound the carry
sum
Checksum (complement)
8 TCP
- TCP provides the end-to-end reliable connection
that IP alone cannot support - The TCP connection primitive is known as the
socket - A socket may be viewed as a bi-directional pipe
(byte stream) between two hosts - Connecting a socket requires a destination IP
address and a port number
9TCP Ports
- Historical convention was that ports numbered
less than 1024 are reserved for standard services
like - Telnet (port 23)
- FTP (21 control, 20 data)
- Email (port 25)
- Secure Shell (ssh, port 22),
- etc. (See a UNIX /etc/services file for more)
10The TCP Protocol
- Frame format
- Connection management
- Flow control
- Congestion control
11 TCP Frame Format
32 bits
Source Port
Destination Port
Sequence Number
Acknowledgement number
Window Size
HL
F I N
S Y N
R S T
P S H
A C K
U R G
Checksum
Urgent Pointer
Options (0 or more 32-bit words)
Data
12TCP Frame Fields
- Source Destination Ports
- 16 bit port identifiers for each packet
- Sequence number
- The packets unique sequence ID
- Acknowledgement number
- The sequence number of the next packet expected
by the receiver
13TCP Frame Fields (contd)
- Window size
- Specifies how many bytes may be sent after the
first acknowledged byte - Checksum
- Checksums the TCP header and IP address fields
- Urgent Pointer
- Points to urgent data in the TCP data field
14TCP Frame Fields (contd)
- Header bits
- URG Urgent pointer field in use
- ACK Indicates whether frame contains
acknowledgement - PSH Data has been pushed. It should be
delivered to higher layers right away. - RST Indicates that the connection should be
reset - SYN Used to establish connections
- FIN Used to release a connection
15 TCP Connection Establishment
Host A
Host B
SYN (seqx)
SYN (seqy, ACKx1)
SYN (seqx1, ACKy1)
16TCP Connection Tear-down
Host A
Host B
FIN (seqx)
ACK (ACKx1)
A-gtB torn down
FIN (seqy)
ACK (ACKy1)
B-gtA torn down
17 TCP Flow Control
- TCP uses a modified version of the sliding window
- In acknowledgements, TCP uses the Window size
field to tell the sender how many bytes it may
transmit - TCP uses bytes, not packets, as sequence numbers
18TCP Flow Control (contd)
Important information in TCP/IP packet headers
Number of bytes in packet (N)
Sequence number of first data byte in packet (SEQ)
N
SEQ
Send
Window size at the receiver (WIN)
Sequence number of next expected byte (ACK)
ACK bit set
ACK
WIN
Recv
Contained in IP header
Contained in TCP header
19Example TCP session
- (1)remus tcpdump -S host scullyKernel
filter, protocol ALL, datagram packet
sockettcpdump listening on all devices - 151522.152339 eth0 gt remus.4706 gt
scully.echo S 12642965041264296504(0) win 32120
ltmss 1460,sack OK,timestamp 71253512 0,nop,wscale
0gt 151522.153865 eth0 lt scully.echo gt
remus.4706 S 875676030875676030(0) ack
1264296505 win 8760 ltmss 1460gt151522.153912
eth0 gt remus.4706 gt scully.echo .
12642965051264296505(0) ack 875676031 win 32120
remus telnet scully 7 A ltreturngt A
20Example TCP session
Timestamp
Source IP/port
Dest IP/port
Packet 1 151522.152339 eth0 gt remus.4706 gt
scully.echo S 12642965041264296504(0) win 32120
ltmss 1460,sackOK,timestamp 71253512 0,nop,wscale
0gt (DF)
Flags
Packet 2 151522.153865 eth0 lt scully.echo gt
remus.4706 S 875676030875676030(0) ack
1264296505 win 8760 ltmss 1460)
Options
Packet 3 151522.153912 eth0 gt remus.4706 gt
scully.echo . 12642965051264296505(0) ack
875676031 win 32120
Window
Start Sequence Number
Acknowledgement Number
End Sequence Number
21TCP data transfer
Packet 4151528.591716 eth0 gt remus.4706 gt
scully.echo P 12642965051264296508(3) ack
875676031 win 32120
data
Packet 5 151528.593255 eth0 lt scully.echo gt
remus.4706 P 875676031875676034(3) ack
1264296508 win 8760
bytes
22TCP Flow Control (contd)
Receivers buffer
Receiver
Sender
Application does a 2K write
0
4K
Empty
ACK 2048 WIN 2048
Application does a 3K write
Full
Sender is blocked
Application reads 2K
ACK 4096 WIN 0
ACK 4096 WIN 2048
Sender may send up to 2K
23TCP Flow Control (contd)
Piggybacking Allows more efficient
bidirectional communication
Data from A to B
ACK for data from B to A
N
SEQ
ACK
WIN
A
B
N
SEQ
ACK
WIN
Data from B to A
ACK for data from A to B
24 TCP Retransmission
- When a packet remains unacknowledged for a period
of time, TCP assumes it is lost and retransmits
it - TCP tries to calculate the round trip time (RTT)
for a packet and its acknowledgement - From the RTT, TCP can guess how long it should
wait before timing out
25Round Trip Time (RTT)
Time for data to arrive
Network
Time for ACK to return
RTT Time for packet to arrive at destination
Time for ACK to return from
destination
26RTT Calculation
Receiver
Sender
0.9 sec
RTT
ACK 2048
2.2 sec
RTT 2.2 sec - 0.9 sec. 1.3 sec
27Smoothing the RTT measurement
- First, we must smooth the round trip time due to
variations in delay within the network -
- SRTT a SRTT (1-a) RTTarriving ACK
- The smoothed round trip time (SRTT) weights
previously received RTTs by the a parameter - a is typically equal to 0.875
28Calculating the Retransmission Timeout Interval
- The timeout value is then calculated by
multiplying the smoothed RTT by some factor
(greater than 1) called b - Timeout b SRTT
- This coefficient of b is included to allow for
some variation in the round trip times.
29Smoothing the RTT measurementExample
Initial SRTT 1.50 a 0.875, b 4.0
RTT Meas.
SRTT
Timeout
1.5 s
1.50
b1.50 6.00
1.0 s
1.50a 1.0(1- a) 1.44
b1.44 5.76
2.2 s
1.44a 2.2(1- a) 1.54
b1.54 6.16
1.0 s
1.54a 1.0(1- a) 1.47
b1.47 5.88
0.8 s
1.47a 0.8(1- a) 1.39
b1.39 5.56
3.1 s
2.0 s
30Problem with RTT Calculation
Receiver
Sender
Sender Timeout
RTT?
ACK 2048
RTT?
31Karns Algorithm
- Retransmission ambiguity
- Measure RTT from original data segment
- Measure RTT from most recent segment
- Either way there is a problem in RTT estimate
- One solution
- Never update RTT measurements based on
acknowledgements from retransmitted packets - Problem Sudden change in RTT can cause system
never to update RTT - Primary path failure leads to a slower secondary
path
32Karns algorithm
- Use back-off as part of RTT computation
- Whenever packet loss, RTO is increased by a
factor - Use this increased RTO as RTT estimate for the
next segment (not from srtt) - Only after an acknowledgment received for a
successful transmission is the timer set to new
RTT obtained from srtt
33Another Problem with RTT Calculation
- RTT measurements can sometimes fluctuate severely
- smoothed RTT (SRTT) is not a good reflection of
round-trip time in these cases - Solution Use Jacobson/Karels algorithm
- Error RTT - SRTT
- SRTT SRTT (a Error)
- Dev Dev h(Error - Dev)
- Timeout SRTT (b Dev)
34Jacobson/Karels AlgorithmExample
Initial SRTT 1.50, Dev 0 a 0.125, d 0.25,
b 4.0
Error RTT - SRTT SRTT SRTT (a Error) Dev
Dev d (Error - Dev) Timeout SRTT (b
Dev)
RTT Meas.
SRTT
Error
Dev.
Timeout
1.5 s
1.50
0.0
0.00
1.50
1.0 s
1.44
-0.50
0.13
1.94
2.2 s
1.54
0.76
0.28
2.67
1.0 s
1.47
-0.54
0.35
2.85
0.8 s
1.39
-0.67
0.43
3.09
3.1 s
2.0 s
35Example RTT computation
36TCP Congestion Control
- Recall Network layer is responsible for
congestion control - However, TCP/IP blurs the distinction
- In TCP/IP
- the network layer (IP) simply handles routing and
packet forwarding - congestion control is done end-to-end by TCP
37Self-Clocking Model
Bottleneck link
Pr
Fast link
Pb
1. Send Burst
2. Receive data packet
5. Send a data packet
Data
Receiver
Sender
Acks
4. Receive Acknowledgement
3. Send Acknowledgement
Ab
Ar
Ar
Given Pb Pr Ar Ab Ar (in units of time)
Sending a packet on each ACK keeps the bottleneck
link busy
38Changing bottleneck bandwidth
- one router, finite buffers
- sender retransmission of lost packet
Host A
lout
lin original data
l'in original data, plus retransmitted data
Host B
finite shared output link buffers
39TCP Congestion Control
- Goal achieve self-clocking state
- Even if dont know bandwidth of bottleneck
- Bottleneck may change over time
- Two phases to keep bottleneck busy
- Slow-start ramps up to the bottleneck limit
- Packet loss signals we passed bandwidth of
bottleneck - Congestion Avoidance tries to maintain self
clocking mode once established
40TCP Congestion Window
- TCP introduces a second window, called the
congestion window - This window maintains TCPs best estimate of
amount of outstanding data to allow in the
network to achieve self-clocking - To determine how many bytes it may send, the
sender takes the minimum of the receiver window
and the congestion window - Example
- If the receiver window says the sender can
transmit 8K, but the congestion window is only
4K, then the sender may only transmit 4K - If the congestion window is 8K but the receiver
window says the sender can transmit 4K, then the
sender may only transmit 4K
41TCP Slow Start Phase
- TCP defines the maximum segment size as the
maximum size a TCP packet can be (including
header) - TCP Slow Start
- Congestion window starts small, at 1 segment size
- Each time a transmitted segment is acknowledged,
the congestion window is increased by one maximum
segment size - On each ack, cwndcwnd 1
42TCP Slow Start (contd)
Congestion Window Size
Event
1K A sends 1 segment to B B ACKs the
segment 2K A sends 2 segments to B B ACKs both
segments 4K A sends 4 segments to B B ACKs all
four segments 8K A sends 8 segments to B B
ACKs all eight segments 16K and so on
43TCP Slow Start (contd)
- Congestion window size grows exponentially (i.e.
it keeps on doubling) - Packet losses indicate congestion
- Packet losses are determined by using timers at
the sender - When a timeout occurs, the congestion window is
reduced to one maximum segment size and
everything starts over
44TCP Slow Start
- When connection begins, increase rate
exponentially until first loss event - double CongWin every RTT
- done by incrementing CongWin for every ACK
received - Summary initial rate is slow but ramps up
exponentially fast
Host A
Host B
one segment
RTT
two segments
four segments
45TCP Slow Start (contd)
Timed out Transmissions
Congestion window
Transmission Number
1 Maximum Segment Size
46TCP Slow Start (contd)
- TCP Slow Start by itself is inefficient
- Although the congestion window builds
exponentially, it drops to 1 segment size every
time a packet times out - This leads to low throughput
47TCP Linear Increase Threshold
- Establish a threshold at which the rate increase
is linear instead of exponential to improve
efficiency - Algorithm
- Start the threshold at 64K (ssthresh)
- Start the congestion window size at 1 segment
size - Increase the congestion window size exponentially
using slow start until the threshold is reached - Once the threshold is passed, only increase the
congestion window size by 1 segment size for each
congestion window of data transmitted - For each ack received, increment cwnd as follows
- cwnd cwnd (mssmss)/cwnd
- Note that cwnd is a multiple of mss for some k
(say kmss) - During the linear phase, if we get k acks then
cwnd increases by 1 mss - If a timeout occurs, reset the congestion window
size to 1 segment and set threshold to 1/2 of
MIN(sliding window, congestion window)
48TCP Linear Increase Threshold Phase
Example Maximum segment size 1K Assume
SSthresh32K
Timeout occurs when MIN(sliding window,
congestion window) 40K
Congestion window
Thresholds
40K
32K
20K
1K
Transmission Number
49TCP Fast Retransmit
- Another enhancement to TCP congestion control
- Idea When sender sees 3 duplicate ACKs, it
assumes something went wrong - The packet is immediately retransmitted instead
of waiting for it to timeout - Why?
- Note that acks sent by the receiver when it
receives a packet - Dup ack implies something is getting through
- Better than time out
50TCP Fast RetransmitExample
Receiver
Sender
MSS 1K
ACK of new data
ACK 2048 WIN 31K
Duplicate ACK 1
ACK 2048 WIN 30K
Duplicate ACK 2
ACK 2048 WIN 29K
Fast Retransmit occurs (2nd packet is
now retransmitted w/o waiting for it to timeout)
Duplicate ACK 3
ACK 2048 WIN 28K
ACK 2048 WIN 27K
ACK 7168 WIN 26K
51TCP Fast Recovery
- Yet another enhancement to TCP congestion control
- Idea Dont do a slow start after a fast
retransmit - Instead, use this algorithm
- Drop threshold to 1/2 of MIN(sliding window,
congestion window) - Set congestion window to threshold 3 MSS
- (ssthresh 3mss)
- For each duplicate ACK (after the fast
retransmit), increment congestion window by MSS - When next non-duplicate ACK arrives, set
congestion window equal to the threshold
52TCP Fast RecoveryExample
Sender
SW29K,TH15K, CW20K
Continuing with the Fast Retransmit Example...
SW28K,TH15K, CW20K
ACK 2048 WIN 28K
Fast Retransmit Occurs
MSS1K Sliding Window (SW) Congestion Threshold
(TH) Congestion Window (CW)
SW28K, TH10K, CW13K
ACK 2048 WIN 27K
SW27K, TH10K, CW14K
ACK 7168 WIN 26K
SW26K, TH10K, CW10K
53Resulting TCP Sawtooth
In steady state, window oscillates around the
bottlenecks capacity (I.e. number of
outstanding bytes in transit)
Congestion window
Slow Start
Bottleneck Capacity
Linear Mode
40K
Sawtooth
32K
20K
1K
Transmission Number
54TCP Recap
- Timeout Computation
- Timeout is a function of 2 values
- the weighted average of sampled RTTs
- The sampled variance of each RTT
- Congestion control
- Goal Keep the self-clocking pipe full in spite
of changing network conditions - 3 key Variables
- Sliding window (Receiver flow control)
- Congestion window (Sender flow control)
- Threshold (Senders slow start vs. linear mode
line) - Slow start
- Add 1 segment for each ACK to the congestion
window - -Doubles the congestion windows volume each
RTT
55TCP Recap (cont)
- Linear mode (Congestion Avoidance)
- Add 1 segments worth of data to each
1/congestion window - Adds 1 segment per RTT
56Algorithm Summary TCP Congestion Control
- When CongWin is below Threshold, sender in
slow-start phase, window grows exponentially. - When CongWin is above Threshold, sender is in
congestion-avoidance phase, window grows
linearly. - When a triple duplicate ACK occurs, Threshold set
to CongWin/2 and CongWin set to Threshold. - When timeout occurs, Threshold set to CongWin/2
and CongWin is set to 1 MSS.
57TCP sender congestion control
58TCP Fairness
- Fairness goal if K TCP sessions share same
bottleneck link of bandwidth R, each should have
average rate of R/K
59Why is TCP fair?
- Two competing sessions
- Additive increase gives slope of 1, as throughout
increases - multiplicative decrease decreases throughput
proportionally
R
equal bandwidth share
loss decrease window by factor of 2
congestion avoidance additive increase
Connection 2 throughput
loss decrease window by factor of 2
congestion avoidance additive increase
Connection 1 throughput
R
60Fairness (more)
- Fairness and UDP
- Multimedia apps often do not use TCP
- do not want rate throttled by congestion control
- Instead use UDP
- pump audio/video at constant rate, tolerate
packet loss - Research area TCP friendly
- Fairness and parallel TCP connections
- nothing prevents app from opening parallel
connections between 2 hosts. - Web browsers do this
- Example link of rate R supporting 9 connections
- new app asks for 1 TCP, gets rate R/10
- new app asks for 11 TCPs, gets R/2 !
61Delay modeling
- Q How long does it take to receive an object
from a Web server after sending a request? - Ignoring congestion, delay is influenced by
- TCP connection establishment
- data transmission delay
- slow start
- Notation, assumptions
- Assume one link between client and server of rate
R - S MSS (bits)
- O object size (bits)
- no retransmissions (no loss, no corruption)
- Window size
- First assume fixed congestion window, W segments
- Then dynamic window, modeling slow start
62Fixed congestion window (1)
- First case
- WS/R gt RTT S/R ACK for first segment in window
returns before windows worth of data sent
delay 2RTT O/R
63Fixed congestion window (2)
- Second case
- WS/R lt RTT S/R wait for ACK after sending
windows worth of data sent
delay 2RTT O/R (K-1)S/R RTT - WS/R
64TCP Delay Modeling Slow Start (1)
- Now suppose window grows according to slow start
- Will show that the delay for one object is
where P is the number of times TCP idles at
server
- where Q is the number of times the server
idles if the object were of infinite size. -
and K is the number of windows that cover the
object.
65TCP Delay Modeling Slow Start (2)
- Delay components
- 2 RTT for connection estab and request
- O/R to transmit object
- time server idles due to slow start
- Server idles P minK-1,Q times
- Example
- O/S 15 segments
- K 4 windows
- Q 2
- P minK-1,Q 2
- Server idles P2 times
66TCP Delay Modeling (3)
67TCP Delay Modeling (4)
Recall K number of windows that cover
object How do we calculate K ?
Calculation of Q, number of idles for
infinite-size object, is similar (see HW).