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/

Goals for Todays 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)

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

Transport Protocols
Provide logical communication
between application processes
running on different hosts

network
data link
physical

l
ca

network
data link
physical

en
den
d

tr

network
data link
physical

t
or
sp
an

Multiple transport protocol

available to applications
Internet: TCP and UDP

network
data link
physical

gi
lo

Run on end hosts

Sender: breaks application
messages into segments,
and passes to network layer
Receiver: reassembles
segments into messages,
passes to application layer

application
transport
network
data link
physical

network
data link
physical
application
transport
network
data link
physical

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

Multiplexing and Demultiplexing

Host receives IP datagrams
Each datagram has source
and destination IP address,
Each datagram carries one
transport-layer segment
Each segment has source
and destination port number
Host uses IP addresses and
port numbers to direct the
segment to appropriate socket

32 bits
source port #

dest port #

other header fields

application
data
(message)
TCP/UDP segment format

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

checksum

length
DATA

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

Popular Applications That Use UDP

Multimedia streaming

Retransmitting lost/corrupted packets is not worthwhile

By the time the packet is retransmitted, its 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

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 receivers 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 couldnt understand Bob?

Bob asks Alice to repeat what she said

What if Bob hasnt 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)

Dont 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 arrives13

TCP Support for Reliable Delivery

Checksum

Sequence numbers

Used to detect corrupted data at the receiver

leading the receiver to drop the packet
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

TCP Stream of Bytes Service

Host A

Byte 80

Byte 3
Byte 2
Byte 1
Byte 0

Host B

Byte 80

Byte 3
Byte 2
Byte 1
Byte 0

16

Emulated Using TCP Segments

Host A
Byte 80

Byte 3
Byte 2
Byte 1
Byte 0

Segment sent when:

TCP Data

Host B

1. Segment full (Max Segment Size),

2. Not full, but times out, or
3. Pushed by application.
TCP Data

Byte 80

Byte 3
Byte 2
Byte 1
Byte 0

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
number = 1st
byte

Host B

TCP Data

TCP
HDR

TCP Data

ACK sequence
number = next
expected byte
TCP
HDR

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

SY N
CK
A
N
Y
S

ACK

B
Each host tells
its ISN to the
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
FIN
RST
PSH
URG
ACK

Acknowledgment
HdrLen 0

Flags

Advertised window

Checksum

Urgent pointer

Options (variable)

Data

23

Step 1: As Initial SYN Packet

As port

Bs port

As Initial Sequence Number

Flags: SYN
FIN
RST
PSH
URG
ACK

Acknowledgment
20

Flags

Checksum

Advertised window
Urgent pointer

Options (variable)

A tells B it wants to open a connection

24

Step 2: Bs SYN-ACK Packet

Bs port

As port

Bs Initial Sequence Number

Flags: SYN
FIN
RST
PSH
URG
ACK

As ISN plus 1
20

Flags

Checksum

Advertised window
Urgent pointer

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: As ACK of the SYN-ACK

As port

Bs port
Sequence number

Flags: SYN
FIN
RST
PSH
URG
ACK

Bs ISN plus 1
20

Flags

Checksum

Advertised window
Urgent pointer

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
acknowledgment (ACK) when
it receives packet
Sender waits for ACK and
timeouts if it does not arrive
within some time period

Timeout

Sender

Receiver

Packe
t
ACK

Simplest ARQ protocol

Stop and wait

Send a packet, stop and wait
until ACK arrives

Time

30

ACK

Packet lost

ACK

Packe
t
ACK

ACK lost
DUPLICATE
PACKET

Timeout

Packe
t

Timeout

Packe
t

Timeout

Packe
t

Timeout

Timeout

Timeout

Reasons for Retransmission

Packe
t
K
C
A
Packe
t
ACK

Early timeout
DUPLICATE
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

33

A Flaw in This Approach

An ACK doesnt 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

Doesnt consider variance in the RTT

If variance is small, the EstimatedRTT is pretty accurate

but, if variance is large, the estimate isnt 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
Thats 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
TCP

Last byte written

Last byte ACKed

Last byte sent

Receiving process
TCP

Last byte read

Next byte expected

Last byte received

38

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 ACKd

Outstanding
Un-ackd data

Data OK
to send

Data not OK
to send yet

39

TCP Header for Receiver Buffering

Source port

Destination port

Sequence number
Flags: SYN
FIN
RST
PSH
URG
ACK

Acknowledgment
HdrLen 0

Flags Advertised window

Checksum

Urgent pointer

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 arent 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

ACK

FI N

Data

ACK

FI N

CK
FI N A

ACK

CK
SY N A

SY N

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()

Process is done sending

data via the socket
Process invokes
close() to close the
socket
Once TCP has sent all of
the outstanding bytes
then TCP sends a FIN

Receiving a FIN: EOF

Process is reading data

from the socket
Eventually, the attempt
to read returns an EOF

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