Chapter 3

Transport Layer

All material copyright 1996-2004

J.F Kurose and K.W. Ross, All Rights Reserved
Computer Networking:
A Top Down Approach
Featuring the Internet,
3rd edition.
Jim Kurose, Keith Ross
Addison-Wesley, July
2004.

Transport Layer 3-1

Chapter 3: Transport Layer
Our goals:
r understand principles r learn about transport
behind transport layer protocols in the
layer services: Internet:
m Multiplexing m UDP: connectionless
m demultiplexing transport
m reliable data transfer m TCP: connection-oriented
m flow control transport
m congestion control m TCP congestion control

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

lo
physical
r transport protocols run in end

gi
data link

ca
physical
systems

le
network

nd
data link
m send side: breaks app data

-e
physical network

n
data link

d
into segments, passes to physical

tr
an
network layer network

sp
data link

or
physical
m rcv side: reassembles

t
segments into data, passes application
transport
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:
m logical communication between hosts

r transport layer:
m logical communication between processes
m relies on and 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 data link
m congestion control network

lo
physical

gi
data link
flow control

ca
m physical

le
network
connection setup

nd
m data link

-e
physical network

n
data link
r unreliable, unordered

d
physical

tr
an
delivery: UDP network

sp
data link

or
physical

t
m no-frills extension of
“best-effort” IP application
transport

r services not available:

network
data link
physical
m delay guarantees
m bandwidth guarantees

Transport Layer 3-5

 Multiplexing/demultiplexing
Multiplexing at send host: Demultiplexing at rcv host:
gathering data from multiple delivering received segments
sockets, enveloping data with to correct socket
header (later used for
demultiplexing)
= socket = process

application P3 P1
P1 application P2 P4 application

transport transport transport

network network network

link link link

physical physical physical

host 2 host 3
host 1
Transport Layer 3-6
How demultiplexing works
r host receives IP datagrams

32 bits
m each datagram has source IP
address, destination IP source port # dest port #
address

m each datagram carries 1 other header fields

transport-layer segment

m each segment has source and

destination port number application
data
r host uses IP addresses & port (message)
numbers to direct segment to
appropriate socket

TCP/UDP segment format

Transport Layer 3-7

Connectionless demultiplexing
r When host receives UDP
r Create sockets with port
numbers: segment:

DatagramSocket mySocket1 = new

m checks destination port
DatagramSocket(9111); number in segment
DatagramSocket mySocket2 = new
DatagramSocket(9222); m directs UDP segment to
socket with that port
number
r UDP socket identified by
two-tuple:
(dest IP address, dest port number)

Transport Layer 3-8

 Connection-oriented demux
r TCP socket identified by r Server host may support
4-tuple: many simultaneous TCP
sockets:
m source IP address m each socket identified by its
m source port number own 4-tuple
m dest IP address
m dest port number r Web servers have different
sockets for each connecting
client
r recv host uses all four values
to direct segment to m non-persistent HTTP will have
different socket for each
appropriate socket
request

Transport Layer 3-9

Connection-oriented demux:
Multi-process Web server

P1 P4 P5 P6 P2 P1P3

SP:
5775
DP: 80
S-IP: B
D-IP:C

SP: SP:
9157 9157
client DP: 80 DP: 80 Client
server
IP: A S-IP: A S-IP: B IP:B
IP: C
D-IP:C D-IP:C

Transport Layer 3-10

UDP: User Datagram Protocol [RFC 768]

r “no frills,” “bare bones”

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

Transport Layer 3-11

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 data
application layer (message)
m application-specific
error recovery!
UDP segment format

Transport Layer 3-12

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

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

Transport Layer 3-13

 Checksum Example
r Note
m When adding numbers, a carryout from the
most significant bit needs to be added to the
result
r 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
Transport Layer 3-14
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-15
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-16

Rdt2.0: channel with bit errors
r underlying channel may flip bits in packet
m 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-17

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
Λ
call from
below
sender
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

Transport Layer 3-18

rdt3.0: channels with errors and loss

New assumption: Approach: sender waits

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

r requires countdown timer

Transport Layer 3-19

rdt3.0 in action

Transport Layer 3-20

rdt3.0 in action

Transport Layer 3-21

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

first packet bit arrives

RTT last packet bit arrives, send ACK

ACK arrives, send next

packet,

Transport Layer 3-22

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

r Two generic forms of pipelined protocols: go-Back-N,

selective repeat
Transport Layer 3-23
Go-Back-N
Sender:
r “window” of up to N, consecutive unack’ed pkts allowed

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

r timer for each in-flight pkt
r timeout(n): retransmit pkt n and all higher seq # pkts in window
r out-of-order pkt:
discard (don’t buffer) -> no receiver buffering!
Re-ACK pkt with highest in-order seq #

Transport Layer 3-24

GBN in
action

Transport Layer 3-25

Selective Repeat
r receiver individually acknowledges all correctly
received pkts
m buffers pkts, as needed, for eventual in-order delivery
to upper layer

r sender only resends pkts for which ACK not

received
m sender timer for each unACKed pkt

r sender window
m N consecutive seq #’s
m again limits seq #s of sent, unACKed pkts

Transport Layer 3-26

Selective repeat in action

Transport Layer 3-27

TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581

r point-to-point: r full duplex data:

m one sender, one receiver m bi-directional data flow
in same connection
r reliable, in-order byte
m MSS: maximum segment
stream: size
m no “message boundaries” r connection-oriented:
r pipelined: m handshaking (exchange
m TCP congestion and flow
of control msgs)
initializes the sender
control set window size
and receiver state
r send & receive buffers before data exchange
r flow controlled:
m sender will not
overwhelm receiver

Transport Layer 3-28

 TCP segment structure
32 bits
URG: urgent data counting
(generally not used) source port # dest port #
by bytes
sequence number of data
ACK: ACK #
valid acknowledgement number (not segments!)
head not
PSH: push data now len used
UA P R S F Receive window
(generally not used) # bytes
checksum Urg data pnter
rcvr willing
RST, SYN, FIN: Options (variable length) to accept
connection estab
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)

Transport Layer 3-29

 TCP seq. #’s and ACKs
Seq. #’s:
Host A Host B
m byte stream
“number” of first User Seq=4
2, ACK
types =79, d
byte in segment’s ‘C’
ata = ‘
C ’
data host ACKs
receipt of
ACKs: ‘C’ ‘C’, echoes
3 , data =
m seq # of next byte K= 4
, AC back ‘C’
Se q=79
expected from
other side host ACKs
m cumulative ACK receipt Seq=4
of echoed 3, ACK
Q: how receiver handles =80
‘C’
out-of-order segments
m A: TCP spec doesn’t
say, - up to time
implementor simple telnet scenario

Transport Layer 3-30

TCP Flow Control
flow control
sender won’t overflow
r receive side of TCP receiver’s buffer by
connection has a transmitting too much,
receive buffer: too fast

r speed-matching
service: matching the
send rate to the
receiving app’s drain
rate
r app process may be
slow at reading from
buffer
Transport Layer 3-31
TCP Flow control: how it works
r Rcvr advertises spare
room by including value
of RcvWindow in
segments

(Suppose TCP receiver r Sender limits unACKed

discards out-of-order data to RcvWindow
segments) m guarantees receive
r spare room in buffer buffer doesn’t overflow
= RcvWindow
= RcvBuffer-[LastByteRcvd -
LastByteRead]

Transport Layer 3-32

TCP Connection Management
Recall: TCP sender, receiver Three way handshake:
establish “connection”
before exchanging data Step 1: client host sends TCP
segments SYN segment to server
r initialize TCP variables: m specifies initial seq #

m seq. #s m no data

m buffers, flow control Step 2: server host receives

info (e.g. RcvWindow) SYN, replies with SYNACK
r client: connection initiator segment
Socket clientSocket = new m server allocates buffers
Socket("hostname","port
m specifies server initial seq.
number");
#
r server: contacted by client Step 3: client receives SYNACK,
Socket connectionSocket =
welcomeSocket.accept();
replies with ACK segment,
which may contain data

Transport Layer 3-33

TCP Connection Management (cont.)

Closing a connection: client server

client closes socket: close

FIN
clientSocket.close();

Step 1: client end system ACK

close
sends TCP FIN control
FIN
segment to server

Step 2: server receives

timed wait
ACK
FIN, replies with ACK.
Closes connection, sends
FIN.
closed

Transport Layer 3-34

TCP Connection Management (cont.)

Step 3: client receives FIN, client server

replies with ACK. closing
FIN
m Enters “timed wait” -
will respond with ACK
to received FINs ACK
closing
Step 4: server, receives FIN

ACK. Connection closed.

timed wait
ACK
Note: with small
modification, can handle closed
simultaneous FINs.
closed

Transport Layer 3-35