Transport Layer

Transport Layer 3-1

Transport Layer
Our goals:
r understand principles
behind transport
layer services:
m multiplexing/demultipl
exing
m reliable data transfer
m flow control
m congestion control
r learn about transport
layer protocols in the
Internet:
m UDP: connectionless
transport
m TCP: connection-oriented
transport
m TCP congestion control –
basic notes
Transport Layer 3-2
Transport services and protocols
r provide logical communication application
transport
between app processes network
data link
running on different hosts physical
network
data link
network physical

lo
r transport protocols run in data link

gi
ca
physical
end systems

le
network

nd
data link
m send side: breaks app

-e
physical network

nd
data link
messages into segments, physical

tr
a
passes to network layer network

ns
data link

po
m rcv side: reassembles
physical

rt
segments into messages, application
transport
passes to app layer network
data link
r more than one transport physical

protocol available to apps

m Internet: TCP and UDP

Transport Layer 3-3

Transport vs. network layer
r network layer: logical
communication
between hosts
r transport layer: logical
communication
between processes
m relies on, enhances,
network layer services

Transport Layer 3-4

Internet transport-layer protocols
r reliable, in-order application
transport

delivery (TCP) network

data link network
physical
congestion control
data link
m network physical

lo
data link

gi
flow control

ca
m physical

le
network
connection setup

nd
data link
m

-e
physical network

nd
data link
r unreliable, unordered physical

tr
a
delivery: UDP network

ns
data link

po
physical

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

m delay guarantees
m bandwidth guarantees

Transport Layer 3-5

Multiplexing/demultiplexing
r Demultiplexing
r Each transport-layer segment
has a set of fields in the
segment for this purpose. At
the receiving end, the
transport layer examines
these fields to identify the
receiving socket and then
directs the segment to that
socket. This job of delivering
the data in a transport-layer
segment to the correct socket
is called demultiplexing.
r Multiplexing
r The job of gathering data
chunks at the source host
from different sockets,
encapsulating each data chunk
with header information to
create segments, and passing
the segments to the network
layer is called multiplexing.
Transport Layer 3-6
 Multiplexing/demultiplexing
Demultiplexing at rcv host: Multiplexing at send host:
gathering data from multiple
delivering received segments
sockets, enveloping data with
to correct socket
header (later used for
demultiplexing)
= socket = process

P3 P1
P1 P2 P4 application
application application

transport transport transport

network network network

link link link

physical physical physical

host 2 host 3
host 1
Transport Layer 3-7
How demultiplexing works
r host receives IP datagrams
m each datagram has source 32 bits
IP address, destination IP
address source port # dest port #

m each datagram carries 1

transport-layer segment other header fields
m each segment has source,
destination port number
(recall: well-known port application
numbers for specific data
applications) (message)
r host uses IP addresses & port
numbers to direct segment to
appropriate socket TCP/UDP segment format

Transport Layer 3-8

Connectionless demultiplexing
r Create sockets with port r When host receives UDP
numbers: segment:
m checks destination port
clientSocket1 = socket(AF_INET, SOCK_DGRAM) number in segment
m directs UDP segment to
clientSocket1.bind(("", 1220))
socket with that port
clientSocket2 = socket(AF_INET, SOCK_DGRAM) number
clientSocket2.bind(("", 1221)) r IP datagrams with
different source IP
UDP socket identified by two- addresses and/or source
tuple: port numbers directed
(dest IP address, dest port number) to same socket

Transport Layer 3-9

 Connectionless demux (cont)
serverSocket = socket(AF_INET, SOCK_DGRAM)
serverSocket.bind(("", 6428))

P2 P1
P1
P3

SP: 6428 SP: 6428

DP: 9157 DP: 5775

SP: 9157 SP: 5775

client DP: 6428 DP: 6428 Client
server
IP: A IP: C IP:B

UDP socket identified by two-tuple:

SP provides “return address” (dest IP address, dest port number)
All segments with same DP routed to same socket
Transport Layer 3-10
Connection-oriented demux
r TCP socket identified r Server host may support
by 4-tuple: many simultaneous TCP
m source IP address sockets:
m source port number m each socket identified by
m dest IP address its own 4-tuple
m dest port number r Web servers have
r recv host uses all four different sockets for
values to direct each connecting client
segment to appropriate
socket

Transport Layer 3-11

Connection-oriented demux
(cont)

P2 P3 P4 P1
P1

SP: 80 SP: 80
DP: 9157 DP: 5775

SP: 9157 SP: 5775

client DP: 80 DP: 80 Client
server
IP: A IP: C IP:B

TCP socket identified by 4-tuple: source IP address, source port number,

dest IP address, dest port number
Segments with same DP can be routed to different sockets!
Transport Layer 3-12
UDP: User Datagram Protocol [RFC 768]
r “no frills,” “bare bones”
Internet transport
protocol
r “best effort” service, UDP
segments may be:
m lost
m delivered out of order
to app
r connectionless:
m no handshaking between
UDP sender, receiver
m each UDP segment
handled independently
of others
Why is there a UDP?
r no connection
establishment (which can
add delay)
r simple: no connection state
at sender, receiver
r small segment header
r no congestion control: UDP
can blast away as fast as
desired
Transport Layer 3-13
 UDP: more
r often used for streaming
multimedia apps 32 bits

m loss tolerant Length, in source port # dest port #

m rate sensitive bytes of UDP length checksum
segment,
r other UDP uses including
m DNS header
m SNMP
r reliable transfer over UDP: Application
add reliability at Simple Network data
application layer
Management Protocol
(SNMP) is a popular (message)
protocol for network
m application-specific management. It is
used for collecting
error recovery! information from, and
configuring, network
devices, such as UDP segment format
servers, printers,
hubs, switches, and
routers on an
Internet Protocol
(IP) network. technet Transport Layer 3-14
UDP checksum
Goal: detect “errors” (e.g., flipped bits) in transmitted
segment

Sender: Receiver:
r treat segment contents r All message data and
as sequence of 16-bit checksum added
integers
together
r checksum: addition (1’s
complement sum) of r Result should be all 1s
segment contents r There may still be
r sender puts checksum errors if two bits may
value into UDP checksum
alternately flip
field

Transport Layer 3-15

 Checksum Data parts

Sender
Add data words

Checksum = 1’s complement

1->0, 0->1

Receiver
Data parts

Checksum

All 1’s expected

Transport Layer 3-16

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

r characteristics of unreliable channel will determine

complexity of reliable data transfer protocol (rdt)
Transport Layer 3-17
Reliable data transfer: getting started
We’ll:
r incrementally develop sender, receiver sides of
reliable data transfer protocol (rdt)
r consider only unidirectional data transfer
m but control info will flow on both directions!
r 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

Transport Layer 3-18

Rdt1.0: reliable transfer over a reliable channel

r underlying channel perfectly reliable

m no bit errors
m no loss of packets
r separate FSMs for sender, receiver:
m sender sends data into underlying channel
m receiver read 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-19

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

Transport Layer 3-20

rdt2.0: FSM specification
rdt_send(data)
snkpkt = 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-21

 Was data

rdt2.0 has a fatal flaw!

received and
delivered to
app
layer(ACK)/
or rejected
What happens if Handling duplicates: (NAK)

ACK/NAK corrupted? r sender adds sequence

r sender doesn’t know what
happened at receiver!
r can’t just retransmit:
possible duplicate
What to do?
r sender ACKs/NAKs
receiver’s ACK/NAK? What
if sender ACK/NAK lost?
r retransmit, but this might
cause retransmission of
correctly received pkt! Can credit a bank account twice for
number to each pkt
r sender retransmits current
pkt if ACK/NAK garbled
r receiver discards (doesn’t
deliver up) duplicate pkt
stop and wait
Sender sends one packet,
then waits for receiver
response
instance!
Transport Layer 3-22
rdt2.2: discussion Need to distinguish between
packet expected and duplicates

Receiver:
Sender:
r must check if received
r seq # added to pkt
packet is duplicate
r two seq. #’s (0,1) will m state indicates whether
suffice. 0 or 1 is expected pkt
r Eliminate NAK only use seq #
ACK r note: receiver can not
r must check if received know if its last ACK
ACK corrupted received OK at sender
r duplicate ACK at
sender results in
retransmit current pkt Transport Layer 3-23
 rdt2.2: sender, receiver fragments
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Wait for Wait for
ACK isACK(rcvpkt,1) )
call 0 from
above 0 udt_send(sndpkt)
sender FSM
fragment rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && && isACK(rcvpkt,0)
(corrupt(rcvpkt) || L
has_seq1(rcvpkt)) Wait for receiver FSM
0 from
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-24