Chapter 3

Transport Layer

A note on the use of these Powerpoint slides:

We’re making these slides freely available to all (faculty, students, readers).
They’re in PowerPoint form so you see the animations; and can add, modify,
and delete slides (including this one) and slide content to suit your needs.

Computer
They obviously represent a lot of work on our part. In return for use, we only
ask the following:

 If you use these slides (e.g., in a class) that you mention their source
(after all, we’d like people to use our book!)
Networking: A Top
 If you post any slides on a www site, that you note that they are adapted
from (or perhaps identical to) our slides, and note our copyright of this
Down Approach
material.
7th Edition, Global Edition
Thanks and enjoy! JFK/KWR
Jim Kurose, Keith Ross
All material copyright 1996-2016 Pearson
J.F Kurose and K.W. Ross, All Rights Reserved April 2016
Transport Layer 2-1
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-2

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

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

processes running on
different hosts

lo
gi
ca
 transport protocols run in end

enl
d-
systems

en
d
• send side: breaks app

tra
ns
messages into segments,

po
rt
passes to network layer
application
• rcv side: reassembles transport
network
segments into messages, data link
physical
passes to app layer
 more than one transport
protocol available to apps
• Internet: TCP and UDP Transport Layer 3-4
Transport vs. network layer
 network layer: household analogy:
logical
communication 12 kids in Ann’s house
sending letters to 12 kids in
between hosts Bill’s house:
 transport layer:  hosts = houses
logical  processes = kids
communication  app messages = letters in
envelopes
between processes  transport protocol = Ann
• relies on, enhances, and Bill who demux to in-
network layer house siblings
services  network-layer protocol =
postal service

Transport Layer 3-5

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

delivery (TCP) data link

physical
network
• congestion control network data link

lo
data link physical

gi
physical
• flow control

ca
network

l
data link

en
• connection setup physical

d-
en
network

d
 unreliable, unordered

tra
data link
physical

ns
delivery: UDP

po
network
data link

rt
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 address,
destination IP address source port # dest port #
• each datagram carries one transport-
layer segment
• each segment has source, destination other header fields
port number
 host uses IP addresses & port
numbers to direct segment to application
appropriate socket data
(payload)

TCP/UDP segment format

Transport Layer 3-9

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

 when host receives UDP IP datagrams with same

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

Transport Layer 3-10

Connectionless demux: example
DatagramSocket serverSocket
= new DatagramSocket
DatagramSocket mySocket2 (6428); DatagramSocket
= new DatagramSocket mySocket1 = new
(9157); DatagramSocket (5775);

application
application P1 application
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-11
 Connection-oriented demux
 TCP socket identified  server host may support
by 4-tuple: 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 each
four values to direct connecting client
segment to appropriate • non-persistent HTTP will
have different socket for
socket each request

Transport Layer 3-12

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

Transport Layer 3-14

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

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

Transport Layer 3-16

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

Transport Layer 3-18

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 koordinatörü
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-19
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-20

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

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

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

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

 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 uniquely state state
determined by next 1 event
event 2
actions

Transport Layer 3-25

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

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 humans pkt on NAK “errors”
receipt offrom
recover
 new mechanisms in rdt2.0 (beyond rdt1.0):
• error detection
during conversation?
• receiver feedback: control msgs (ACK,NAK) rcvr-
>sender

Transport Layer 3-27

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

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

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for call
 from below

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

Transport Layer 3-29

rdt2.0: operation with no errors
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)

rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for call Wait for rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
from above ACK or NAK
udt_send(sndpkt)
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for call
 from below

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

Transport Layer 3-30

rdt2.0: error scenario
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)

rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for call Wait for rdt_rcv(rcvpkt) &&
corrupt(rcvpkt)
from above ACK or NAK
udt_send(sndpkt)
udt_send(NAK)

rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for call
 from below

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

Transport Layer 3-31

rdt2.0 has a fatal flaw!
what happens if handling duplicates:
ACK/NAK corrupted?  sender retransmits current
 sender doesn’t know what pkt if ACK/NAK corrupted
happened at 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-32

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



Wait for ACK Wait for
or NAK 1 call 1 from
rdt_rcv(rcvpkt) && above
( corrupt(rcvpkt) ||
isNAK(rcvpkt) )
rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt) udt_send(sndpkt)

Transport Layer 3-33

 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) && rdt_rcv(rcvpkt) &&

(corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum) (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt) udt_send(sndpkt)

Wait for Wait for

0 from 1 from
rdt_rcv(rcvpkt) && rdt_rcv(rcvpkt) &&
below below
not corrupt(rcvpkt) && 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-34

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 know if its last
• state must “ remember” ACK/NAK received
whether “ expected” OK at sender
pkt should have seq #
of 0 or 1

Transport Layer 3-35

rdt2.2: a NAK-free protocol
 same functionality as rdt2.1, using ACKs only
 instead of NAK, receiver sends ACK for last pkt
received OK
• receiver must explicitly include seq # of pkt being ACKed
 duplicate ACK at sender results in same action as
NAK: retransmit current pkt

Transport Layer 3-36

 rdt2.2: sender, receiver fragments
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Wait for ACK isACK(rcvpkt,1) )
Wait for call
0 from above 0
udt_send(sndpkt)
sender FSM
fragment rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) ||
has_seq1(rcvpkt)) 
Wait for
0 from receiver FSM
udt_send(sndpkt) below fragment
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt)

Transport Layer 3-37

rdt3.0: channels with errors and loss

new assumption: approach: sender waits

underlying channel can “ reasonable” amount of
also lose packets (data, time for ACK
ACKs)  retransmits if no ACK
• checksum, seq. #, received in this time
ACKs, retransmissions  if pkt (or ACK) just delayed
(not lost):
will be of help … but
not enough • retransmission will be
duplicate, but seq. #’s
already handles this
• receiver must specify seq
# of pkt being ACKed
 requires countdown timer

Transport Layer 3-38

rdt3.0 sender
rdt_send(data) rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) ||
udt_send(sndpkt) isACK(rcvpkt,1) )
start_timer
rdt_rcv(rcvpkt) 
 Wait for Wait for
call 0from ACK0 timeout
above udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt,0)
stop_timer
stop_timer

Wait for Wait for

timeout ACK1 call 1 from
udt_send(sndpkt) above
start_timer rdt_rcv(rcvpkt)
rdt_send(data) 
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) || sndpkt = make_pkt(1, data, checksum)
isACK(rcvpkt,0) ) udt_send(sndpkt)
start_timer

Transport Layer 3-39

 rdt3.0 in action
sender receiver sender receiver
send pkt0 pkt0 send pkt0 pkt0
rcv pkt0 rcv pkt0
ack0 send ack0 ack0 send ack0
rcv ack0 rcv ack0
send pkt1 pkt1 send pkt1 pkt1
rcv pkt1 X
ack1 send ack1 loss
rcv ack1
send pkt0 pkt0
rcv pkt0 timeout
ack0 send ack0 resend pkt1 pkt1
rcv pkt1
ack1 send ack1
rcv ack1
send pkt0 pkt0
(a) no loss rcv pkt0
ack0 send ack0

(b) packet loss

Transport Layer 3-40
 rdt3.0 in action
sender receiver
sender receiver send pkt0 pkt0
send pkt0 pkt0 rcv pkt0
ack0 send ack0
rcv pkt0
send ack0 rcv ack0
ack0 send pkt1 pkt1
rcv ack0 rcv pkt1
send pkt1 pkt1
rcv pkt1 send ack1
ack1 ack1
send ack1
X
loss timeout
resend pkt1 pkt1
rcv pkt1
timeout
resend pkt1 pkt1 rcv ack1 pkt0 (detect duplicate)
rcv pkt1 send pkt0 send ack1
(detect duplicate) ack1
ack1 send ack1 rcv ack1 rcv pkt0
rcv ack1 ack0 send ack0
pkt0 send pkt0 pkt0
send pkt0 rcv pkt0
rcv pkt0 ack0 (detect duplicate)
ack0 send ack0 send ack0

(c) ACK loss (d) premature timeout/ delayed ACK

Transport Layer 3-41

Performance of rdt3.0
 rdt3.0 is correct, but performance stinks
 e.g.: 1 Gbps link, 15 ms prop. delay, 8000 bit packet:
L 8000 bits
Dtrans = R = = 8 microsecs
109 bits/sec

 U sender: utilization – fraction of time sender busy sending

U L/R .008
sender = = = 0.00027
RTT + L / R 30.008

 if RTT=30 msec, 1KB pkt every 30 msec: 33kB/sec thruput over 1 Gbps link
 network protocol limits use of physical resources!

Transport Layer 3-42

 rdt3.0: stop-and-wait operation
sender receiver
first packet bit transmitted, t = 0
last packet bit transmitted, t = L / R

first packet bit arrives

RTT last packet bit arrives, send
ACK

ACK arrives, send next

packet, t = RTT + L / R

U L/R .008
sender = = = 0.00027
RTT + L / R 30.008

Transport Layer 3-43

Pipelined protocols
pipelining: sender allows multiple, “ in-flight” , yet-
to-be-acknowledged pkts
• range of sequence numbers must be increased
• buffering at sender and/or receiver

 two generic forms of pipelined protocols: go-Back-N,

selective repeat
Transport Layer 3-44
 Pipelining: increased utilization
sender receiver
first packet bit transmitted, t = 0
last bit transmitted, t = L / R

first packet bit arrives

RTT last packet bit arrives, send ACK
last bit of 2nd packet arrives, send ACK
last bit of 3rd packet arrives, send ACK
ACK arrives, send next
packet, t = RTT + L / R
3-packet pipelining increases
utilization by a factor of 3!

U 3L / R .0024
sender = = = 0.00081
RTT + L / R 30.008

Transport Layer 3-45