Chapter 3: Transport Layer

our goals:
 understand principles  learn about Internet
behind transport transport layer protocols:
layer services: • UDP: connectionless
• multiplexing, transport
demultiplexing • TCP: connection-oriented
• reliable data transfer reliable transport
• flow control • TCP congestion control
• congestion control

Transport Layer 3-1

Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
3.2 multiplexing and • segment structure
demultiplexing • reliable data transfer
3.3 connectionless • flow control
transport: UDP • connection management
3.4 principles of reliable 3.6 principles of congestion
data transfer control
3.7 TCP congestion control

Transport Layer 3-2

Transport services and protocols
application
transport
 provide logical communication network
data link
between app processes physical

running on different hosts

 transport protocols run in
end systems
• send side: breaks app
messages into segments,
passes to network layer
• rcv side: reassembles application
segments into messages, transport
network
passes to app layer data link
physical

 more than one transport

protocol available to apps
• Internet: TCP and UDP
Transport Layer 3-3
Transport vs. network layer
 network layer: logical household analogy:
communication
between hosts 12 kids in Ann’s house sending
letters to 12 kids in Bill’s
 transport layer: house:
logical  hosts = houses
communication  processes = kids
between processes  app messages = letters in
envelopes
• relies on, enhances,  transport protocol = Ann
network layer and Bill who demux to in-
services house siblings
 network-layer protocol =
postal service

Transport Layer 3-4

Internet transport-layer protocols
application
 reliable, in-order transport
network

delivery (TCP) data link

physical
network

• congestion control network

data link
data link
physical
physical
• flow control network
data link

• connection setup physical

network

 unreliable, unordered data link

physical

delivery: UDP network

data link
physical
• no-frills extension of network
data link application
“best-effort” IP physical
network
data link
transport
network
data link
 services not available: physical
physical

• delay guarantees
• bandwidth guarantees

Transport Layer 3-6

Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
3.2 multiplexing and • segment structure
demultiplexing • reliable data transfer
3.3 connectionless • flow control
transport: UDP • connection management
3.4 principles of reliable 3.6 principles of congestion
data transfer control
3.7 TCP congestion control

Transport Layer 3-7

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

application

application P1 P2 application socket

P3 transport P4
process
transport network transport
network link network
link physical link
physical physical

Transport Layer 3-8

How demultiplexing works
 host receives IP datagrams 32 bits
• each datagram has source IP source port # dest port #
address, destination IP
address
other header fields
• each datagram carries one
transport-layer segment
• each segment has source, application
destination port number data
 host uses IP addresses & (payload)
port numbers to direct
segment to appropriate
TCP/UDP segment format
socket

Transport Layer 3-10

 Connectionless demultiplexing
 recall: created socket has  recall: when creating
host-local port #: datagram to send into UDP
DatagramSocket mySocket1 socket, must specify
= new DatagramSocket(12534);
• destination IP address
or system implicitly assign • destination port #

 when host receives UDP IP datagrams with same

segment: dest. port #, but different
• checks destination port # source IP addresses
in segment and/or source port
numbers will be directed
• directs UDP segment to to same socket at dest
socket with that port #

Transport Layer 3-11

 Example app: UDP client
Python UDPClient
include Python’s socket
from socket import *
library Implicitly assign a port
serverName = ‘hostname’ number to UDP client

serverPort = 12000
create UDP socket for clientSocket = socket(AF_INET,
client
SOCK_DGRAM)
get user keyboard
input message = raw_input(’Input lowercase sentence:’)
Attach server name, port to clientSocket.sendto(message.encode(),
message; send into socket
(serverName, serverPort))
read reply characters from modifiedMessage, serverAddress =
socket into string
clientSocket.recvfrom(2048)
print out received string print modifiedMessage.decode()
and close socket
clientSocket.close()
Application Layer 2-12
Connectionless: example
DatagramSocket
DatagramSocket serverSocket = new
DatagramSocket DatagramSocket
mySocket2 = new mySocket1 = new
DatagramSocket (6428); DatagramSocket
(9157); application
(5775);
application application
P1
P3 P4
transport
transport transport
network
network link network
link physical link
physical physical

source port: 6428 source port: ?

dest port: 9157 dest port: ?

source port: 9157 source port: ?

dest port: 6428 dest port: ?
Transport Layer 3-13
Connectionless: example
DatagramSocket
DatagramSocket serverSocket = new
DatagramSocket DatagramSocket
mySocket2 = new mySocket1 = new
DatagramSocket (6428); DatagramSocket
(9157); application
(5775);
application application
P1
P3 P4
transport
transport transport
network
network link network
link physical link
physical physical

source port: 6428 source port: ?

dest port: 9157 dest port: ?

source port: 9157 source port: ?

dest port: 6428 dest port: ?
Transport Layer 3-14
 Connection-oriented demux
 TCP socket identified  server host may support
by 4-tuple (pipe index): many simultaneous TCP
• source IP address sockets:
• source port number • each socket identified by
• dest IP address its own 4-tuple
• dest port number  web servers have
 demux: receiver uses all different sockets for
four values to direct each connecting client
segment to appropriate • non-persistent HTTP will
socket have different socket for
each request

Transport Layer 3-15

 Connection-oriented demux: 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 Transport Layer 3-16
 Connection-oriented demux: 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
A separate socket for each connection
Transport Layer 3-17
Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
3.2 multiplexing and • segment structure
demultiplexing • reliable data transfer
3.3 connectionless • flow control
transport: UDP • connection management
3.4 principles of reliable 3.6 principles of congestion
data transfer control
3.7 TCP congestion control

Transport Layer 3-18

UDP: User Datagram Protocol [RFC 768]
 “no frills,” “bare bones”  UDP use:
Internet transport  streaming multimedia
protocol apps (loss tolerant, rate
 “best effort” service, UDP sensitive)
segments may be:  DNS
• lost  SNMP
• delivered out-of-order  reliable transfer over
to app
UDP:
 connectionless:
 add reliability at
• no handshaking application layer
between UDP sender,
receiver  application-specific error
recovery!
• each UDP segment
handled independently
of others
Transport Layer 3-19
UDP: segment header
length, in bytes of
32 bits UDP segment,
source port # dest port # including header

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

Transport Layer 3-20

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

Transport Layer 3-21

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

* Check out the online interactive exercises for more

examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Transport Layer 3-22
Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
3.2 multiplexing and • segment structure
demultiplexing • reliable data transfer
3.3 connectionless • flow control
transport: UDP • connection management
3.4 principles of reliable 3.6 principles of congestion
data transfer control
3.7 TCP congestion control

Transport Layer 3-23

Principles of reliable data transfer
 important in application, transport, link layers
• top-10 list of important networking topics!

 characteristics of unreliable channel will determine

complexity of reliable data transfer protocol (rdt)
Transport Layer 3-24
Principles of reliable data transfer
 important in application, transport, link layers
• top-10 list of important networking topics!

 characteristics of unreliable channel will determine

complexity of reliable data transfer protocol (rdt)
Transport Layer 3-25
Principles of reliable data transfer
 important in application, transport, link layers
• top-10 list of important networking topics!

 characteristics of unreliable channel will determine

complexity of reliable data transfer protocol (rdt)
Transport Layer 3-26
Reliable data transfer: getting started
rdt_send(): called from above, deliver_data(): called by
(e.g., by app.). Passed data to rdt to deliver data to upper
deliver to receiver upper layer

send receive
side side

udt_send(): called by rdt, rdt_rcv(): called when packet

to transfer packet over arrives on rcv-side of channel
unreliable channel to receiver

Transport Layer 3-27

Reliable data transfer: getting started
we’ll:
 incrementally develop sender, receiver sides of
reliable data transfer protocol (rdt)
 consider only unidirectional data transfer
• but control info will flow on both directions!
 use finite state machines (FSM) to specify sender,
receiver
event causing state transition
actions taken on state transition
state: when in this
“state” next state state state
uniquely determined 1 event
by next event 2
actions

Transport Layer 3-29

rdt1.0: reliable transfer over a reliable channel
 underlying channel perfectly reliable
• no bit errors
• no loss of packets
 separate FSMs for sender, receiver:
• sender sends data into underlying channel
• receiver reads data from underlying channel

Wait for rdt_send(data) Wait for rdt_rcv(packet)

call from call from extract (packet,data)
above packet = make_pkt(data) below deliver_data(data)
udt_send(packet)

sender receiver

Transport Layer 3-30

rdt2.0: channel with bit errors
 underlying channel may flip bits in packet
• checksum to detect bit errors
 the question: how to recover from errors:
• acknowledgements (ACKs): receiver explicitly tells sender
that pkt received OK
• negative acknowledgements (NAKs): receiver explicitly tells
sender that pkt had errors
• sender
Howretransmits
do humanspkt on receipt from
recover of NAK“errors”
 new mechanisms in rdt2.0 (beyond rdt1.0):
• error detection
during conversation?
• receiver feedback: control msgs (ACK,NAK) rcvr-
>sender

Transport Layer 3-31

rdt2.0: channel with bit errors
 underlying channel may flip bits in packet
• checksum to detect bit errors
 the question: how to recover from errors:
• acknowledgements (ACKs): receiver explicitly tells sender
that pkt received OK
• negative acknowledgements (NAKs): receiver explicitly tells
sender that pkt had errors
• sender retransmits pkt on receipt of NAK
 new mechanisms in rdt2.0 (beyond rdt1.0):
• error detection
• feedback: control msgs (ACK,NAK) from receiver to
sender

Transport Layer 3-32

rdt2.0: FSM specification
rdt_send(data)
sndpkt = make_pkt(data, checksum) receiver
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt) &&
call from ACK or udt_send(sndpkt) corrupt(rcvpkt)
above NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
L
call from
sender below

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Transport Layer 3-33

rdt2.0: operation with no errors
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt) &&
call from ACK or udt_send(sndpkt) corrupt(rcvpkt)
above NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
L call from
below

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Transport Layer 3-34

rdt2.0: error scenario
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for Wait for rdt_rcv(rcvpkt) &&
call from ACK or udt_send(sndpkt) corrupt(rcvpkt)
above NAK
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
L call from
below

rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Transport Layer 3-35

rdt2.0 has a fatal flaw!
what happens if handling duplicates:
ACK/NAK corrupted?  sender retransmits
 sender doesn’t know current pkt if ACK/NAK
what happened at corrupted
receiver!
 sender adds sequence
 can’t just retransmit: number to each pkt
possible duplicate
 receiver discards (doesn’t
deliver up) duplicate pkt
stop and wait
sender sends one packet,
then waits for receiver
response

Transport Layer 3-36

rdt2.1: sender, handles garbled ACK/NAKs
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Wait for Wait for
ACK or
isNAK(rcvpkt) )
call 0 from
NAK 0 udt_send(sndpkt)
above
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt) && notcorrupt(rcvpkt)
&& isACK(rcvpkt)
L
L
Wait for Wait for
ACK or call 1 from
rdt_rcv(rcvpkt) && NAK 1 above
( corrupt(rcvpkt) ||
isNAK(rcvpkt) ) rdt_send(data)

udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)

udt_send(sndpkt)

Transport Layer 3-38

 rdt2.1: receiver, handles garbled ACK/NAKs
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
Wait for Wait for
rdt_rcv(rcvpkt) && 0 from 1 from rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && below below not corrupt(rcvpkt) &&
has_seq1(rcvpkt) has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)

extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)

Transport Layer 3-39

 rdt2.1: receiver, handles garbled ACK/NAKs
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt) rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
Wait for Wait for
rdt_rcv(rcvpkt) && 0 from 1 from rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && below below not corrupt(rcvpkt) &&
has_seq1(rcvpkt) has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)

extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)

Transport Layer 3-40

rdt2.1: discussion
sender: receiver:
 seq # added to pkt  must check if received
 two seq. #’s (0,1) will packet is duplicate
suffice. Why? • state indicates whether
0 or 1 is expected pkt
 must check if received seq #
ACK/NAK corrupted
 note: receiver can not
 twice as many states directly know if its last
• state must ACK/NAK received
“remember” whether OK at sender; but can
“expected” pkt should
have seq # of 0 or 1 infer

Transport Layer 3-41