Transport Layer

Reference to Chapter 3 in book

“Computer Networking: A Top-Down Approach”

Part I

Transport Layer 3-1

 Chapter 3: Transport Layer
our goals:
• understand principles behind transport layer
services:
– multiplexing, demultiplexing
– reliable data transfer
– flow control
– congestion
• learn control transport layer
about Internet
protocols:
– UDP: connectionless transport
– TCP: connection-oriented
Transport Layerreliable transport 3-2
 Transport services and protocols
application
transport
 provide logical communication network
data link
between app processes running on physical

different hosts

lo
 transport protocols run in end systems

gi
ca
le
 sender side: breaks app

nd
-e
nd
messages into segments,

tra
ns
passes to network layer

po
rt
 receiver side: reassembles application

segments into messages,

transport
network
data link
passes to app layer physical

 more than one transport protocol

available to apps
 Internet: TCP and UDP Transport Layer 3-3
 Internet transport-layer protocols
application
• Reliable, in-order delivery (TCP) transport
network
data link
– congestion control physical
network
– flow control network data link

lo
data link physical

gi
physical
– connection setup

ca
network

l
en
data link

• Unreliable, unordered delivery: physical

d-
en
network

d
UDP

tra
data link
physical

ns
• services not available:

p
network

or
data link

t
physical
network

– delay guarantees data link

physical
network
application
transport
network
data link

– bandwidth guarantees physical data link

physical

Transport Layer 3-4

 Multiplexing/demultiplexing
multiplexing at sender:
handle data from multiple demultiplexing at receiver:
sockets, add transport header use header info to deliver
(later used for demultiplexing) received segments to correct
socket

A socket is defined by an IP
application
address and a port
application P1 P2 application socket
P3 transport P4
process
transport network transport
network link network
link physical link
physical physical

Transport Layer 3-5

 How demultiplexing works
Host receives IP 32 bits

datagrams source port # dest port #

 each datagram has source IP address,

destination IP address other header fields
 each datagram carries one transport-
layer segment
application
 each segment has source, destination
data
port number (payload)
Host uses IP addresses &
port numbers to direct TCP/UDP segment format

segment to appropriate
socket Transport Layer 3-6
 Connectionless demultiplex: example

DatagramSocket mySocket2 = DatagramSocket serverSocket =

new DatagramSocket(9157); new DatagramSocket (6428);
application
application P1
P3
transport
transport
network
network link
link physical
physical

If segments from two different IP addresses

source port: 6428
dest port: 9157 have the same destination IP address and
port number, such segments will be directed
to the same process
source port: 9157
dest port: 6428
Transport Layer 3-7
 Connection-oriented demultiplex
 TCP socket identified by 4-tuple:
 source IP address
 source port number
 dest IP address
 dest port number

 demultiplex: receiver uses all four values to direct segment to

appropriate socket
 server host may support many simultaneous TCP sockets:
 each socket identified by its own 4-tuple

Transport Layer 3-8

 Connection-oriented demultiplex: example

application
application P4 P5 P6 application
P3 P2 P3
transport
transport transport
network
network link network
link physical link
physical server: IP physical
address B

host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80
three segments, all destined to IP address: B,
dest port: 80 are demultiplexed to different sockets
3-9
Transport Layer
Connection-oriented demultiplex: example
threaded server
application
application application
P4
P3 P2 P3
transport
transport transport
network
network link network
link physical link
physical server: IP physical
address B

host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
dest IP,port: B,80
source IP,port: A,9157
dest IP, port: B,80
source IP,port: C,9157
dest IP,port: B,80

Transport Layer 3-10

 UDP: User Datagram Protocol [RFC 768]
• “best effort” service, UDP segments may be:
– lost
– delivered out-of-order to app

• connectionless:
– no handshaking between UDP sender and receiver
– each UDP segment is handled independently of others

 UDP use:
 streaming multimedia apps (loss tolerant, rate sensitive)
 DNS

Transport Layer 3-11

 UDP: segment header
length, in bytes of UDP
32 bits segment, including
source port # dest port # header

length checksum
why is there a UDP?
 no connection establishment
application (which can add delay)
data
(payload)  simple: no connection state
at sender, receiver
 small header size
 no congestion control: UDP
UDP segment format can blast away as fast as
desired

Transport Layer 3-12

 UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted segment

sender: receiver:
• treat segment contents, • compute checksum of received
including header fields,
as sequence of 16-bit segment
integers • check if computed checksum
• checksum: addition equals checksum field value:
(one’s complement sum) – NO - error detected
of segment contents – YES - no error detected. But
• sender puts checksum maybe errors nonetheless? More
value into UDP checksum later ….
field

Transport Layer 3-13

 Internet checksum: example

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

wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1

sum 1 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 1 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

Note: when adding numbers, a carryout from the most

significant bit needs to be added to the result

Transport Layer 3-14

 Transmission Control Protocol (TCP)
• Connection oriented
– Explicit set-up and tear-down of TCP session
• 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

15
 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?”

16
 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

17
 Challenges of Reliable Data Transfer
• Over a perfectly reliable channel
– 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

18