Transport Protocols

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
between application processes
running on different hosts application
transport
network
data link
• Run on end hosts physical
network
data link
network physical

lo
– Sender: breaks application data link

gi
ca
physical

l
network
messages into segments,

en
data link

d-
physical network

en
and passes to network layer data link

d
physical

tr
– Receiver: reassembles

an
network

sp
data link

or
segments into messages, physical

t
passes to application layer application
transport
network

• Multiple transport protocol data link

physical

available to applications
– Internet: TCP and UDP 4
Internet Transport Protocols
• Datagram messaging service (UDP)
• Reliable, in-order delivery (TCP)
– Connection set-up
– Discarding of corrupted packets
– Retransmission of lost packets
– Flow control
– Congestion control

• 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 data
port numbers to direct the (message)
segment to 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

checksum length

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 arrives13
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 1. Segment full (Max Segment Size),
2. Not full, but times out, or
3. “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 byte
TCP
TCP Data HDR
Host B

19
Initial Sequence Number (ISN)
• Sequence number for the very first byte
• 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 CK 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 Fields

23
TCP Header Fields
• Source & Destination Ports:
– 16-Bits ports (Identifies a program currently running on a
given Host)

• Source & Acknowledgement Sequence Numbers

– Just Byte counters
– Initial value established at the start of TCP session
– Two sets of Sequence number – one count bytes from A
to B and other from B to A
– Acknowledgement sequence number must be one
greater than the received source sequence number

• Data Offset
– Tells about the length of the TCP header 24
TCP Header Fields
• Flags
– URG : Value in urgent pointer field is significant and
should be examined by the recipient
– ACK : value in ACK sequence num is significant
– PSH : Push all queued input to the application on the
receiving side
– RST : Reset the connection
– SYN: Synchronize the receiver on a sequence number
– FIN : Used to teardown session

• Window Size
– 16 – bit window used by TCP as a buffer management
strategy commonly refered as “Sliding Window”
25
TCP Header Fields
• Checksum
– Used to help ensure the integrity of message
– Computer on both header as well as Payload

• Urgent pointer
– A 16 bit integer value used to indicate how much urgent
data follows the TCP Header

26
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…

27
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 28

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 29

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

30
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
31
END

32