Transport Protocols

Reading: Sections 2.5, 5.1, and 5.2

COS 461: Computer Networks
Spring 2006 (MW 1:30-2:50 in Friend 109)

Jennifer Rexford
Teaching Assistant: Mike Wawrzoniak
http://www.cs.princeton.edu/courses/archive/spring06/cos461/

1
Goals for Today’s Lecture
• Principles underlying transport-layer services
– (De)multiplexing
– Detecting corruption
– Reliable delivery
– Flow control
• Transport-layer protocols in the Internet
– User Datagram Protocol (UDP)
– Transmission Control Protocol (TCP)

2
Role of Transport Layer
• Application layer
– Communication for specific applications
– E.g., HyperText Transfer Protocol (HTTP), File Transfer
Protocol (FTP), Network News Transfer Protocol (NNTP)
• Transport layer
– Communication between processes (e.g., socket)
– Relies on network layer and serves the application layer
– E.g., TCP and UDP
• Network layer
– Logical communication between nodes
– Hides details of the link technology
– E.g., IP
3
Transport Protocols
• Provide logical communication be-
tween application processes running
on different hosts applica-
tion
transport

• Run on end hosts network

data link
network
data link

lo
physical network physical

gi
– Sender: breaks application mes- data link

ca
physical

l
sages into segments,

en
network

d-
data link

en
and passes to network layer
physical network
data link

d
physical

tr
– Receiver: reassembles segments

a
ns
network

po
data link
into messages, passes to applica- physical

r t
tion layer applica-
tion

• Multiple transport protocol available transport

network
data link

to applications physical

– Internet: TCP and UDP

4
Internet Transport Protocols
• Datagram messaging service (UDP)
– No-frills extension of “best-effort” IP
• Reliable, in-order delivery (TCP)
– Connection set-up
– Discarding of corrupted packets
– Retransmission of lost packets
– Flow control
– Congestion control (next lecture)
• Other services not available
– Delay guarantees
– Bandwidth guarantees
5
Multiplexing and Demultiplexing
• Host receives IP datagrams
32 bits
– Each datagram has source and
destination IP address, source port # dest port #
– Each datagram carries one
transport-layer segment other header fields
– Each segment has source and
destination port number
application
• Host uses IP addresses and port data
numbers to direct the segment to (message)
appropriate socket
TCP/UDP segment format

6
Unreliable Message Delivery Service
• Lightweight communication between processes
– Avoid overhead and delays of ordered, reliable delivery
– Send messages to and receive them from a socket
• User Datagram Protocol (UDP)
– IP plus port numbers to support (de)multiplexing
– Optional error checking on the packet contents

SRC port DST port

check- lengt
sum h
DATA

7
Why Would Anyone Use UDP?
• Finer control over what data is sent and when
– As soon as an application process writes into the socket
– … UDP will package the data and send the packet
• No delay for connection establishment
– UDP just blasts away without any formal preliminaries
– … which avoids introducing any unnecessary delays
• No connection state
– No allocation of buffers, parameters, sequence #s, etc.
– … making it easier to handle many active clients at once
• Small packet header overhead
– UDP header is only eight-bytes long
8
Popular Applications That Use UDP
• Multimedia streaming
– Retransmitting lost/corrupted packets is not worthwhile
– By the time the packet is retransmitted, it’s too late
– E.g., telephone calls, video conferencing, gaming
• Simple query protocols like Domain Name System
– Overhead of connection establishment is overkill
– Easier to have application retransmit if needed

“Address for www.cnn.com?”

“12.3.4.15” 9
Transmission Control Protocol (TCP)
• Connection oriented
– Explicit set-up and tear-down of TCP session
• Stream-of-bytes service
– Sends and receives a stream of bytes, not messages
• Reliable, in-order delivery
– Checksums to detect corrupted data
– Acknowledgments & retransmissions for reliable delivery
– Sequence numbers to detect losses and reorder data
• Flow control
– Prevent overflow of the receiver’s buffer space
• Congestion control
– Adapt to network congestion for the greater good
10
An Analogy: Talking on a Cell Phone
• Alice and Bob on their cell phones
– Both Alice and Bob are talking
• What if Alice couldn’t understand Bob?
– Bob asks Alice to repeat what she said
• What if Bob hasn’t heard Alice for a while?
– Is Alice just being quiet?
– Or, have Bob and Alice lost reception?
– How long should Bob just keep on talking?
– Maybe Alice should periodically say “uh huh”
– … or Bob should ask “Can you hear me now?” 

11
Some Take-Aways from the Example
• Acknowledgments from receiver
– Positive: “okay” or “ACK”
– Negative: “please repeat that” or “NACK”
• Timeout by the sender (“stop and wait”)
– Don’t wait indefinitely without receiving some response
– … whether a positive or a negative acknowledgment
• Retransmission by the sender
– After receiving a “NACK” from the receiver
– After receiving no feedback from the receiver

12
Challenges of Reliable Data Transfer
• Over a perfectly reliable channel
– All of the data arrives in order, just as it was sent
– Simple: sender sends data, and receiver receives data
• Over a channel with bit errors
– All of the data arrives in order, but some bits corrupted
– Receiver detects errors and says “please repeat that”
– Sender retransmits the data that were corrupted
• Over a lossy channel with bit errors
– Some data are missing, and some bits are corrupted
– Receiver detects errors but cannot always detect loss
– Sender must wait for acknowledgment (“ACK” or “OK”)
– … and retransmit data after some time if no ACK arrives
13
TCP Support for Reliable Delivery
• Checksum
– Used to detect corrupted data at the receiver
– …leading the receiver to drop the packet
• Sequence numbers
– Used to detect missing data
– ... and for putting the data back in order
• Retransmission
– Sender retransmits lost or corrupted data
– Timeout based on estimates of round-trip time
– Fast retransmit algorithm for rapid retransmission

14
TCP Segments

15
 16
TCP “Stream of Bytes” Service

Byte 80
Byte 3
Byte 2
Byte 1
Byte 0
Byte 80
Byte 3
Byte 2
Byte 1
Byte 0

Host A

Host B
…Emulated Using TCP “Segments”

Host A
Byte 0
Byte 1
Byte 2
Byte 3

Byte 80

Segment sent when:

TCP Data • Segment full (Max Segment Size),
• Not full, but times out, or
• “Pushed” by application.

TCP Data
Host B
Byte 0
Byte 1
Byte 2
Byte 3

Byte 80

17
TCP Segment
IP Data
TCP Data (segment) TCP Hdr IP Hdr

• IP packet
– No bigger than Maximum Transmission Unit (MTU)
– E.g., up to 1500 bytes on an Ethernet
• TCP packet
– IP packet with a TCP header and data inside
– TCP header is typically 20 bytes long
• TCP segment
– No more than Maximum Segment Size (MSS) bytes
– E.g., up to 1460 consecutive bytes from the stream 18
Sequence Numbers
Host A
ISN (initial sequence number)

Sequence TCP
TCP Data
number = 1st HDR

byte ACK sequence

number =
next expected
TCP
byte
TCP Data HDR
Host B

19
Initial Sequence Number (ISN)
• Sequence number for the very first byte
– E.g., Why not a de facto ISN of 0?
• Practical issue
– IP addresses and port #s uniquely identify a connection
– Eventually, though, these port #s do get used again
– … and there is a chance an old packet is still in flight
– … and might be associated with the new connection
• So, TCP requires changing the ISN over time
– Set from a 32-bit clock that ticks every 4 microseconds
– … which only wraps around once every 4.55 hours!
• But, this means the hosts need to exchange ISNs
20
TCP Three-Way Handshake

21
Establishing a TCP Connection
A B
SY N

SY N A
C K Each host tells
its ISN to the
ACK other host.
Data
Data

• Three-way handshake to establish connection

– Host A sends a SYN (open) to the host B
– Host B returns a SYN acknowledgment (SYN ACK)
– Host A sends an ACK to acknowledge the SYN ACK
22
TCP Header

Source port Destination port

Sequence number
Flags: SYN
Acknowledgment
FIN
RST HdrLen 0 Flags Advertised window
PSH
URG Checksum Urgent pointer
ACK Options (variable)

Data

23
Step 1: A’s Initial SYN Packet

A’s port B’s port

A’s Initial Sequence Number

Flags: SYN
Acknowledgment
FIN
RST 20 0 Flags Advertised window
PSH
URG Checksum Urgent pointer
ACK Options (variable)

A tells B it wants to open a connection…

24
Step 2: B’s SYN-ACK Packet

B’s port A’s port

B’s Initial Sequence Number

Flags: SYN
A’s ISN plus 1
FIN
RST 20 0 Flags Advertised window
PSH
URG Checksum Urgent pointer
ACK Options (variable)

B tells A it accepts, and is ready to hear the next byte…

… upon receiving this packet, A can start sending data 25

Step 3: A’s ACK of the SYN-ACK

A’s port B’s port

Sequence number
Flags: SYN
B’s ISN plus 1
FIN
RST 20 0 Flags Advertised window
PSH
URG Checksum Urgent pointer
ACK Options (variable)

A tells B it wants is okay to start sending

… upon receiving this packet, B can start sending data 26

What if the SYN Packet Gets Lost?
• Suppose the SYN packet gets lost
– Packet is lost inside the network, or
– Server rejects the packet (e.g., listen queue is full)
• Eventually, no SYN-ACK arrives
– Sender sets a timer and wait for the SYN-ACK
– … and retransmits the SYN-ACK if needed
• How should the TCP sender set the timer?
– Sender has no idea how far away the receiver is
– Hard to guess a reasonable length of time to wait
– Some TCPs use a default of 3 or 6 seconds

27
SYN Loss and Web Downloads
• User clicks on a hypertext link
– Browser creates a socket and does a “connect”
– The “connect” triggers the OS to transmit a SYN
• If the SYN is lost…
– The 3-6 seconds of delay may be very long
– The user may get impatient
– … and click the hyperlink again, or click “reload”
• User triggers an “abort” of the “connect”
– Browser creates a new socket and does a “connect”
– Essentially, forces a faster send of a new SYN packet!
– Sometimes very effective, and the page comes fast
28
TCP Retransmissions

29
Automatic Repeat reQuest (ARQ)

• Automatic Repeat Request

– Receiver sends acknowledg-
ment (ACK) when it receives
Sender Receiver
packet
– Sender waits for ACK and Pa c k e
t

Timeout
timeouts if it does not arrive
within some time period
ACK
• Simplest ARQ protocol
– Stop and wait Time
– Send a packet, stop and wait
until ACK arrives
30
Reasons for Retransmission

Pa c k e Pa c k e Pa c k e
t t t
Timeout

Timeout

Timeout
ACK C K
A
Pa c k e
Pa c k e Pa c k e t
t t
Timeout

Timeout

Timeout
ACK
ACK ACK

ACK lost Early timeout

Packet lost
DUPLICATE DUPLICATE
PACKET PACKETS
31
How Long Should Sender Wait?
• Sender sets a timeout to wait for an ACK
– Too short: wasted retransmissions
– Too long: excessive delays when packet lost
• TCP sets timeout as a function of the RTT
– Expect ACK to arrive after an RTT
– … plus a fudge factor to account for queuing
• But, how does the sender know the RTT?
– Can estimate the RTT by watching the ACKs
– Smooth estimate: keep a running average of the RTT
 EstimatedRTT = a * EstimatedRTT + (1 –a ) * SampleRTT
– Compute timeout: TimeOut = 2 * EstimatedRTT

32
Example RTT Estimation
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

350

300

250
RTT (milliseconds)

200

150

100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)

SampleRTT Estimated RTT

33
A Flaw in This Approach
• An ACK doesn’t really acknowledge a transmission
– Rather, it acknowledges receipt of the data
• Consider a retransmission of a lost packet
– If you assume the ACK goes with the 1st transmission
– … the SampleRTT comes out way too large
• Consider a duplicate packet
– If you assume the ACK goes with the 2nd transmission
– … the Sample RTT comes out way too small
• Simple solution in the Karn/Partridge algorithm
– Only collect samples for segments sent one single time

34
Yet Another Limitation…
• Doesn’t consider variance in the RTT
– If variance is small, the EstimatedRTT is pretty accurate
– … but, if variance is large, the estimate isn’t all that good
• Better to directly consider the variance
– Consider difference: SampleRTT – EstimatedRTT
– Boost the estimate based on the difference
• Jacobson/Karels algorithm
– See Section 5.2 of the Peterson/Davie book for details

35
TCP Sliding Window

36
Motivation for Sliding Window
• Stop-and-wait is inefficient
– Only one TCP segment is “in flight” at a time
– Especially bad when delay-bandwidth product is high
• Numerical example
– 1.5 Mbps link with a 45 msec round-trip time (RTT)
 Delay-bandwidth product is 67.5 Kbits (or 8 KBytes)
– But, sender can send at most one packet per RTT
 Assuming a segment size of 1 KB (8 Kbits)
 … leads to 8 Kbits/segment / 45 msec/segment  182 Kbps
 That’s just one-eighth of the 1.5 Mbps link capacity

37
Sliding Window
• Allow a larger amount of data “in flight”
– Allow sender to get ahead of the receiver
– … though not too far ahead

Sending process Receiving process

TCP TCP
Last byte written Last byte read

Next byte expected

Last byte ACKed

Last byte received 38

Last byte sent
Receiver Buffering
• Window size
– Amount that can be sent without acknowledgment
– Receiver needs to be able to store this amount of data
• Receiver advertises the window to the receiver
– Tells the receiver the amount of free space left
– … and the sender agrees not to exceed this amount

Window Size

Data ACK’d Outstanding Data OK Data not OK

Un-ack’d data to send to send yet 39
TCP Header for Receiver Buffering

Source port Destination port

Sequence number
Flags: SYN
Acknowledgment
FIN
RST HdrLen 0 Flags Advertised window
PSH
URG Checksum Urgent pointer
ACK Options (variable)

Data

40
Fast Retransmission

41
Timeout is Inefficient
• Timeout-based retransmission
– Sender transmits a packet and waits until timer expires
– … and then retransmits from the lost packet onward

42
Fast Retransmission
• Better solution possible under sliding window
– Although packet n might have been lost
– … packets n+1, n+2, and so on might get through
• Idea: have the receiver send ACK packets
– ACK says that receiver is still awaiting nth packet
 And repeated ACKs suggest later packets have arrived
– Sender can view the “duplicate ACKs” as an early hint
 … that the nth packet must have been lost
 … and perform the retransmission early

• Fast retransmission
– Sender retransmits data after the triple duplicate ACK

43
Effectiveness of Fast Retransmit
• When does Fast Retransmit work best?
– Long data transfers
 High likelihood of many packets in flight
– High window size
 High likelihood of many packets in flight
– Low burstiness in packet losses
 Higher likelihood that later packets arrive successfully

• Implications for Web traffic

– Most Web transfers are short (e.g., 10 packets)
 Short HTML files or small images
– So, often there aren’t many packets in flight
– … making fast retransmit less likely to “kick in”
– Forcing users to like “reload” more often… 
44
Tearing Down the Connection

45
Tearing Down the Connection

SY N A

F IN A
A CK

A CK
ACK
SY N

F IN
FIN
Data

CK
CK

A
time

• Closing the connection

– Finish (FIN) to close and receive remaining bytes
– And other host sends a FIN ACK to acknowledge
– Reset (RST) to close and not receive remaining bytes
46
Sending/Receiving the FIN Packet
• Sending a FIN: close() • Receiving a FIN: EOF
– Process is done sending – Process is reading data
data via the socket from the socket
– Process invokes “close()” to – Eventually, the attempt to
close the socket read returns an EOF
– Once TCP has sent all of
the outstanding bytes…
– … then TCP sends a FIN

47
Conclusions
• Transport protocols
– Multiplexing and demultiplexing
– Sequence numbers
– Window-based flow control
– Timer-based retransmission
– Checksum-based error detection
• Reading for this week
– Sections 2.5, 5.1-5.2, and 6.1-6.4
• Next lecture
– Congestion control

48