Chapter 3: Transport Layer

Chapter goals: Chapter Overview:

 understand principles  transport layer services
behind transport layer  multiplexing/demultiplexing
services:  connectionless transport: UDP
 multiplexing/  principles of reliable data
demultiplexing
transfer
 reliable data transfer
 connection-oriented transport:
 flow control
TCP
 congestion control
 instantiation and
 reliable transfer
 flow control
implementation in the
Internet
 connection management
 principles of congestion control
 TCP congestion control

3: Transport Layer 3a-1

Transport services and protocols
 provide logical communication application
transport
between app’ processes network
data link
running on different hosts physical
network
data link
network physical

lo
 transport protocols run in end data link

gi
ca
physical
systems

le
network

nd
data link
 transport vs network layer

-e
physical network

nd
data link
services: physical

tr
an
network
 network layer: data transfer

s
data link

po
physical

rt
between end systems
 transport layer: data application
transport

transfer between processes network

data link
physical
 relies on, enhances, network
layer services

3: Transport Layer 3a-2

Transport-layer protocols

Internet transport services: application

transport
 reliable, in-order unicast network
data link network
delivery (TCP) physical
network
data link
physical

lo
 congestion data link

gi
ca
physical
flow control

le
 network

nd
data link
connection setup

-e
 physical network

nd
data link
physical
 unreliable (“best-effort”),

tr
an
network
unordered unicast or

s
data link

po
physical

rt
multicast delivery: UDP
 services not available: application
transport
network
 real-time data link
physical
 bandwidth guarantees
 reliable multicast

3: Transport Layer 3a-3

 Multiplexing/demultiplexing
Recall: segment - unit of data
Demultiplexing: delivering
exchanged between
received segments to
transport layer entities correct app layer processes
 aka TPDU: transport
protocol data unit
receiver
P3 P4
application-layer M M
data
application
segment P1 transport P2
M
header M network
application application
segment Ht M transport transport
network
Hn segment network

3: Transport Layer 3a-4

Multiplexing/demultiplexing
Multiplexing:
gathering data from multiple 32 bits
app processes, enveloping
data with header (later used source port # dest port #
for demultiplexing)
other header fields
multiplexing/demultiplexing:
 based on sender, receiver
port numbers, IP addresses
application
 source, dest port #s in
data
each segment (message)
 recall: well-known port
numbers for specific
applications TCP/UDP segment format

3: Transport Layer 3a-5

Multiplexing/demultiplexing: examples
source port: x Web client
host A dest. port: 23 server B host C

source port:23
dest. port: x
Source IP: C Source IP: C
Dest IP: B Dest IP: B
source port: y source port: x
port use: simple telnet app dest. port: 80 dest. port: 80

Source IP: A
Dest IP: B Web
Web client source port: x server B
host A dest. port: 80
port use: Web server

3: Transport Layer 3a-6

UDP: User Datagram Protocol [RFC 768]

 “no frills,” “bare bones”

Internet transport Why is there a UDP?
protocol  no connection
 “best effort” service, UDP
establishment (which can
segments may be: add delay)
 lost  simple: no connection state
 delivered out of order at sender, receiver
to app  small segment header
 connectionless:  no congestion control: UDP
 no handshaking between can blast away as fast as
UDP sender, receiver desired
 each UDP segment
handled independently
of others

3: Transport Layer 3a-7

UDP: more
 often used for streaming
multimedia apps 32 bits
 loss tolerant
Length, in source port # dest port #
 rate sensitive bytes of UDP length checksum
segment,
 other UDP uses
including
(why?): header
 DNS
 SNMP Application
 reliable transfer over UDP: data
(message)
add reliability at
application layer
 application-specific
UDP segment format
error recover!

3: Transport Layer 3a-8

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

Sender: Receiver:
 treat segment contents as  compute checksum of
sequence of 16-bit received segment
integers  check if computed checksum
 checksum: addition (1’s equals checksum field value:
complement sum) of  NO - error detected
segment contents  YES - no error detected.
 sender puts checksum But maybe errors
value into UDP checksum nonethless? More later ….
field

3: Transport Layer 3a-9

Principles of Reliable data transfer
 important in app., transport, link layers
 top-10 list of important networking topics!

 characteristics of unreliable channel will determine complexity of reliable data transfer protocol
(rdt)

3: Transport Layer 3a-10

 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

3: Transport Layer 3a-11

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

3: Transport Layer 3a-12

Rdt1.0: reliable transfer over a reliable channel

 underlying channel perfectly reliable

 no bit erros
 no loss of packets

 separate FSMs for sender, receiver:

 sender sends data into underlying channel
 receiver read data from underlying channel

3: Transport Layer 3a-13

Rdt2.0: channel with bit errors
 underlying channel may flip bits in packet
 recall: UDP 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
 human scenarios using ACKs, NAKs?
 new mechanisms in rdt2.0 (beyond rdt1.0):
 error detection
 receiver feedback: control msgs (ACK,NAK) rcvr->sender

3: Transport Layer 3a-14

rdt2.0: FSM specification

sender FSM receiver FSM

3: Transport Layer 3a-15
rdt2.0: in action (no errors)

sender FSM receiver FSM

3: Transport Layer 3a-16
rdt2.0: in action (error scenario)

sender FSM receiver FSM

3: Transport Layer 3a-17
rdt2.0 has a fatal flaw!
What happens if Handling duplicates:
ACK/NAK corrupted?  sender adds sequence
 sender doesn’t know what number to each pkt
happened at receiver!  sender retransmits current
 san’t just retransmit: pkt if ACK/NAK garbled
possible duplicate  receiver discards (doesn’t
deliver up) duplicate pkt
What to do?
 sender ACKs/NAKs
receiver’s ACK/NAK? What stop and wait
Sender sends one packet,
if sender ACK/NAK lost?
then waits for receiver
 retransmit, but this might
response
cause retransmission of
correctly received pkt!
3: Transport Layer 3a-18
rdt2.1: sender, handles garbled
ACK/NAKs

3: Transport Layer 3a-19

rdt2.1: receiver, handles garbled ACK/NAKs

3: Transport Layer 3a-20

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 OK
whether “current” pkt
at sender
has 0 or 1 seq. #

3: Transport Layer 3a-21

rdt2.2: a NAK-free protocol
 same functionality as
sender
FSM
rdt2.1, using NAKs 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
3: Transport Layer 3a-22
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
or ACKs)  retransmits if no ACK
 checksum, seq. #, ACKs, received in this time
retransmissions will be  if pkt (or ACK) just delayed
of help, but not enough (not lost):
 retransmission will be
Q: how to deal with loss?
duplicate, but use of seq.
 sender waits until
#’s already handles this
certain data or ACK
 receiver must specify seq
lost, then retransmits
# of pkt being ACKed
 yuck: drawbacks?
 requires countdown timer

3: Transport Layer 3a-23

rdt3.0 sender

3: Transport Layer 3a-24

rdt3.0 in action

3: Transport Layer 3a-25

rdt3.0 in action

3: Transport Layer 3a-26

Performance of rdt3.0
 rdt3.0 works, but performance stinks
 example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:

8kb/pkt
Ttransmit = = 8 microsec
10**9 b/sec
fraction of time 8 microsec
Utilization = U = sender busy sending = = 0.00015
30.016 msec
 1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link
 network protocol limits use of physical resources!

3: Transport Layer 3a-27

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
3: Transport Layer 3a-28
Go-Back-N
Sender:
 k-bit seq # in pkt header
 “window” of up to N, consecutive unack’ed pkts allowed

 ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK”

 may deceive duplicate ACKs (see receiver)
 timer for each in-flight pkt
 timeout(n): retransmit pkt n and all higher seq # pkts in window

3: Transport Layer 3a-29

GBN: sender extended FSM

3: Transport Layer 3a-30

GBN: receiver extended FSM

receiver simple:
 ACK-only: always send ACK for correctly-received pkt
with highest in-order seq #
 may generate duplicate ACKs
 need only remember expectedseqnum
 out-of-order pkt:
 discard (don’t buffer) -> no receiver buffering!
 ACK pkt with highest in-order seq #

3: Transport Layer 3a-31

GBN in
action

3: Transport Layer 3a-32

Selective Repeat
 receiver individually acknowledges all correctly
received pkts
 buffers pkts, as needed, for eventual in-order delivery
to upper layer
 sender only resends pkts for which ACK not
received
 sender timer for each unACKed pkt
 sender window
 N consecutive seq #’s
 again limits seq #s of sent, unACKed pkts

3: Transport Layer 3a-33

Selective repeat: sender, receiver windows

3: Transport Layer 3a-34

Selective repeat
sender receiver
data from above : pkt n in [rcvbase, rcvbase+N-1]
 if next available seq # in  send ACK(n)
window, send pkt  out-of-order: buffer

timeout(n):  in-order: deliver (also

 resend pkt n, restart timer deliver buffered, in-order
pkts), advance window to
ACK(n) in [sendbase,sendbase+N]: next not-yet-received pkt
 mark pkt n as received
pkt n in [rcvbase-N,rcvbase-1]
 if n smallest unACKed pkt,
 ACK(n)
advance window base to
next unACKed seq # otherwise:
 ignore

3: Transport Layer 3a-35

Selective repeat in action

3: Transport Layer 3a-36

Selective repeat:
dilemma
Example:
 seq #’s: 0, 1, 2, 3
 window size=3

 receiver sees no
difference in two
scenarios!
 incorrectly passes
duplicate data as new in
(a)

Q: what relationship
between seq # size and
window size?
3: Transport Layer 3a-37