Chapter 3

Transport
Layer

Computer
Networking: A
Top Down
Approach
6th edition
Jim Kurose, Keith
Ross
Addison-Wesley
March 2012

Transport Layer 3-1

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

Transport Layer 3-2

Chapter 3 outline
3.1 transport-layer 3.5 connection-
services oriented transport:
3.2 multiplexing TCP
 segment structure
and
demultiplexing  reliable data transfer
 flow control
3.3 connectionless  connection
transport: UDP management
3.4 principles of 3.6 principles of
reliable data congestion control
transfer
3.7 TCP congestion
control
Transport Layer 3-3
Transport services and
protocols applicatio
n
 provide logical transport

communication between network

data link
app processes running on physical

different hosts

lo
gi
ca
 transport protocols run in

enl
end systems

d-
en
 send side: breaks app

d
tr
messages into

a
ns
segments, passes to

po
network layer

r
t
 rcv side: reassembles applicatio
n
segments into transport
network
messages, passes to data link
physical
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
between hosts kids in Bill’s house:
 transport layer:  hosts = houses

logical  processes = kids

communication  app messages =

letters in envelopes
between  transport protocol =
processes Ann and Bill who
 relies on, demux to in-house
enhances, siblings
network layer  network-layer
services protocol = postal
service
Transport Layer 3-5
Internet transport-layer
protocols applicatio
 reliable, in-order n
transport
delivery (TCP) network
data link
network
 congestion control physical

lo
network data link

gi
data link physical
 flow control

ca
physical
network

l en
 connection setup data link

d-
physical

en
 unreliable, network

d
data link

tr
unordered delivery:

a
physical

ns
network

po
UDP data link

r
physical

t
network
 no-frills extension of data link
physical
applicatio
n
“best-effort” IP network
data link transport
network
physical
 services not data link
physical

available:
 delay guarantees
 bandwidth
guarantees Transport Layer 3-6
Chapter 3 outline
3.1 transport-layer 3.5 connection-
services oriented transport:
3.2 multiplexing TCP
 segment structure
and
demultiplexing  reliable data transfer
 flow control
3.3 connectionless  connection
transport: UDP management
3.4 principles of 3.6 principles of
reliable data congestion control
transfer
3.7 TCP congestion
control
Transport Layer 3-7
 Multiplexing/
demultiplexing
multiplexing at sender:
handle data from demultiplexing at receiver:
multiple use header info to deliver
sockets, add transport received segments to corre
header (later used for socket
demultiplexing)
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, other header fields
destination 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
 recall: when creating
datagram to send into UDP
has host-local port #: socket, must specify
DatagramSocket mySocket1  destination IP address
= new  destination port #
DatagramSocket(12534);

 when host receives IP datagrams with

UDP segment: same dest. port #,
 checks destination but different source
port # in segment IP addresses and/or
source port numbers
 directs UDP segment will be directed to
to socket with that same socket at dest
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  server host may
identified by 4- support many
tuple: simultaneous TCP
 source IP address sockets:
 source port number  each socket identified
by its own 4-tuple
 dest IP address
 dest port number
 web servers have
different sockets for
 demux: receiver each connecting
uses all four values client
to direct segment  non-persistent HTTP
to appropriate will have different
socket socket for 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: physical
IP
address
B
host: IP source IP,port: B,80 host: IP
address dest IP,port: A,9157 source IP,port: C,5775 address
A dest IP,port: B,80 C
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: physical
IP
address
B
host: IP source IP,port: B,80 host: IP
address dest IP,port: A,9157 source IP,port: C,5775 address
A dest IP,port: B,80 C
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-
services oriented transport:
3.2 multiplexing TCP
 segment structure
and
demultiplexing  reliable data transfer
 flow control
3.3 connectionless  connection
transport: UDP management
3.4 principles of 3.6 principles of
reliable data congestion control
transfer
3.7 TCP congestion
control
Transport Layer 3-15
UDP: User Datagram Protocol
[RFC 768]
 “no frills,” “bare bones”  UDP use:
Internet transport  streaming
protocol
multimedia apps
 “best effort” service,
UDP segments may be: (loss tolerant, rate
 lost sensitive)
 delivered out-of-order  DNS
to app  SNMP
 connectionless:  reliable transfer
 no handshaking
between UDP sender, over UDP:
receiver  add reliability at
 each UDP segment application layer
handled  application-specific
independently of error recovery!
others

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
data can 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
including header fields, received segment
as sequence of 16-bit  check if computed
integers
checksum equals
 checksum: addition checksum field value:
(one’s complement  NO - error detected
sum) of segment
contents  YES - no error detected.
 sender puts checksum But maybe errors
value into UDP nonetheless? More later
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 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

Transport Layer 3-19

Chapter 3 outline
3.1 transport-layer 3.5 connection-
services oriented transport:
3.2 multiplexing TCP
 segment structure
and
demultiplexing  reliable data transfer
 flow control
3.3 connectionless  connection
transport: UDP management
3.4 principles of 3.6 principles of
reliable data congestion control
transfer
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
(e.g., by app.). Passed data to by rdt to deliver data to
deliver to receiver upper layer upper

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

Transport Layer 3-25

Finite State Machines
A finite state machine or finite automaton is a
model of behavior composed of states, transitions
and actions.
 A state stores information about the past, i.e. it reflects the
input changes from the system start to the present moment.
 A transition indicates a state change and is described by
a condition/event that would need to be fulfilled to enable
the transition.
 An action is a description of an activity that is to be
performed at a given moment.
 Ref: http://en.wikipedia.org
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-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
How do humansinrecover
new mechanisms from rdt1.0
rdt2.0 (beyond “errors”
):
during conversation?
 error detection
 receiver feedback: control msgs (ACK,NAK) rcvr-
>sender

Transport Layer 3-28

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

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

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

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

rdt2.0 has a fatal flaw!
what happens if handling duplicates:
ACK/NAK  sender retransmits current
corrupted? pkt if ACK/NAK corrupted
 sender adds sequence
 sender doesn’t know number to each pkt
what happened at  receiver discards (doesn’t
receiver! deliver up) duplicate pkt
 can’t just retransmit:
possible duplicate

stop and wait

sender sends one
packet,
then waits for
receiver
response Transport Layer 3-33
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-34

 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) Sender re-sends seq# 0

deliver_data(data) due to a garbled ACK/NAK
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)

Transport Layer 3-35

rdt2.1: discussion
sender: receiver:
 seq # added to pkt  must check if
 two seq. #’s (0,1)
received packet is
will suffice. Why? duplicate
 must check if  state indicates
received ACK/NAK whether 0 or 1 is
corrupted expected pkt seq
 twice as many #
states  note: receiver can
 state must not know if its last
“remember” whether ACK/NAK received
“expected” pkt
should have seq # of OK at sender
0 or 1
Transport Layer 3-36
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-37

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

rdt3.0: channels with errors and
loss
new assumption: approach: sender waits
underlying “reasonable” amount
channel can also of time for ACK
lose packets  retransmits if no ACK
received in this time
(data, ACKs)  if pkt (or ACK) just
 checksum, seq. #, delayed (not lost):
ACKs,  retransmission will be
retransmissions duplicate, but seq. #’s
will be of help … already handles this
but not enough  receiver must specify
seq # of pkt being
ACKed
 requires countdown
timer
Transport Layer 3-39
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-40

 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-41
 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-42

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 = 9 = 8 microsecs
10 bits/sec
U sender : utilization – fraction of time sender busy sending

 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-43

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

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-45
 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-46

Pipelined protocols:
overview
Go-back-N: Selective Repeat:
 sender can have  sender can have up to

up to N unacked N unack’ed packets in

packets in pipeline pipeline
 receiver only sends  receiver sends

cumulative ack individual ack for each

packet
 doesn’t ack packet
if there’s a gap
 sender has timer  sender maintains
for oldest unacked timer for each
packet unacked packet
 when timer expires,  when timer expires,
retransmit all retransmit only that
unacked packets unacked packet
Transport Layer 3-47
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 receive duplicate ACKs (see receiver)
 timer for oldest in-flight pkt
 timeout(n): retransmit packet n and all higher seq # pkts in window

Transport Layer 3-48

 GBN in action
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
send pkt2 receive pkt0, send ack0
012345678
send pkt3 Xloss receive pkt1, send ack1
012345678
(wait)
receive pkt3, discard,
012345678 rcv ack0, send pkt4 (re)send ack1
012345678 rcv ack1, send pkt5 receive pkt4, discard,
(re)send ack1
ignore duplicate ACK receive pkt5, discard,
(re)send ack1
pkt 2 timeout
012345678 send pkt2
012345678 send pkt3
012345678 send pkt4 rcv pkt2, deliver, send ack2
012345678 send pkt5 rcv pkt3, deliver, send ack3
rcv pkt4, deliver, send ack4
rcv pkt5, deliver, send ack5

Transport Layer 3-49

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
 limits seq #s of sent, unACKed pkts

Transport Layer 3-50

Selective repeat: sender, receiver
windows

Transport Layer 3-51

Selective repeat
sender receiver
data from above: pkt n in [rcvbase,
rcvbase+N-1]
 if next available seq #
in window, send pkt
 send ACK(n)
timeout(n):
 out-of-order: buffer
 resend pkt n, restart
 in-order: deliver (also
timer deliver buffered, in-
order pkts), advance
ACK(n) in window to next not-
[sendbase,sendbase+N]:
yet-received pkt
 mark pkt n as
received pkt n in [rcvbase-
N,rcvbase-1]
 if n smallest unACKed  ACK(n)
pkt, advance window
base to next unACKed otherwise:
seq #  ignore
Transport Layer 3-52
 Selective repeat in action
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
send pkt2 receive pkt0, send ack0
012345678
send pkt3 Xloss receive pkt1, send ack1
012345678
(wait)
receive pkt3, buffer,
012345678 rcv ack0, send pkt4 send ack3
012345678 rcv ack1, send pkt5 receive pkt4, buffer,
send ack4
record ack3 arrived receive pkt5, buffer,
send ack5
pkt 2 timeout
012345678 send pkt2
012345678 record ack4 arrived
012345678 rcv pkt2; deliver pkt2,
record ack5 arrived
012345678 pkt3, pkt4, pkt5; send ack2

Q: what happens when ack2 does not arrive?

Transport Layer 3-53

Chapter 3 outline
3.1 transport-layer 3.5 connection-
services oriented transport:
3.2 multiplexing TCP
 segment structure
and
demultiplexing  reliable data transfer
 flow control
3.3 connectionless  connection
transport: UDP management
3.4 principles of 3.6 principles of
reliable data congestion control
transfer
3.7 TCP congestion
control
Transport Layer 3-54
TCP: Overview RFCs: 793,1122,1323,
2018, 2581

 point-to-point:  full duplex data:

 one sender, one  bi-directional data flow
receiver in same connection
 MSS: maximum
 reliable, in-order segment size
byte steam:  connection-oriented:
 no “message  handshaking
boundaries” (exchange of control
msgs) inits sender,
 pipelined: receiver state before
 TCP congestion and data exchange
flow control set  flow controlled:
window size  sender will not
overwhelm receiver

Transport Layer 3-55

 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
UAP R S F receive window
(generally not used) # bytes
checksum Urg data pointer
rcvr willing
RST, SYN, FIN: to accept
options (variable length)
connection estab
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)

Transport Layer 3-56

Chapter 3 outline
3.1 transport-layer 3.5 connection-
services oriented transport:
3.2 multiplexing TCP
 segment structure
and
demultiplexing  reliable data transfer
 flow control
3.3 connectionless  connection
transport: UDP management
3.4 principles of 3.6 principles of
reliable data congestion control
transfer
3.7 TCP congestion
control
Transport Layer 3-57
TCP reliable data transfer
 TCP creates rdt
service on top of
IP’s unreliable
service
 pipelined segments
 cumulative acks
 single
retransmission timer
 retransmissions
triggered by:
 timeout events
 duplicate acks

Transport Layer 3-58

TCP sender events:
data rcvd from app: timeout:
 create segment with  retransmit segment
seq # that caused timeout
 seq # is byte-  restart timer
stream number of ack rcvd:
first data byte in  if ack acknowledges
segment
 start timer if not
previously unacked
segments
already running  update what is
 think of timer as for
known to be ACKed
oldest unacked  start timer if there
segment
 expiration interval: are still unacked
segments
TimeOutInterval

Transport Layer 3-59

TCP: retransmission
scenarios
Host A Host B Host A Host B

SendBase=92
Seq=92, 8 bytes of data Seq=92, 8 bytes of data

Seq=100, 20 bytes of data

timeo

timeo
ACK=100
ut

ut
X
ACK=100
ACK=120

Seq=92, 8 bytes of data Seq=92, 8

SendBase=100 bytes of data
SendBase=120
ACK=100
ACK=120

SendBase=120

lost ACK scenario premature timeout

Transport Layer 3-60
TCP: retransmission
scenarios
Host A Host B

Seq=92, 8 bytes of data

Seq=100, 20 bytes of data

ACK=100
timeo

X
ut

ACK=120

Seq=120, 15 bytes of data

cumulative ACK
Transport Layer 3-61
TCP fast
retransmit
 time-out period
often relatively TCP fast retransmit
long: if sender receives 3
 long delay before ACKs for same data
resending lost packet
(“tripleduplicate
(“triple duplicateACKs”),
 detect lost ACKs”), resend
segments via unacked segment
duplicate ACKs. with smallest seq #
 sender often sends
 likely that unacked
many segments
back-to-back segment lost, so
 if segment is lost, don’t wait for
timeout
there will likely be
many duplicate ACKs.

Transport Layer 3-62

TCP fast
retransmit
Host A Host B

Seq=92, 8 bytes of data

Seq=100, 20 bytes of data
X

ACK=100
timeo

ACK=100
ut

ACK=100
ACK=100
Seq=100, 20 bytes of data

fast retransmit after sender

receipt of triple duplicate ACK
Transport Layer 3-63
Chapter 3 outline
3.1 transport-layer 3.5 connection-
services oriented transport:
3.2 multiplexing TCP
 segment structure
and
demultiplexing  reliable data transfer
 flow control
3.3 connectionless  connection
transport: UDP management
3.4 principles of 3.6 principles of
reliable data congestion control
transfer
3.7 TCP congestion
control
Transport Layer 3-64
TCP flow control
application
Application process
removes data from application
TCP socket buffers ….
TCP socket OS
receiver buffers

receiver is
delivering TCP
(sender is code
sending)

IP
flow control code
receiver controls sender,
so sender won’t overflow
receiver’s buffer by from sender
transmitting too much,
receiver protocol stack
too fast

Transport Layer 3-65

TCP flow control
 receiver “advertises”
free buffer space by to application process
including rwnd value in
TCP header of receiver-
to-sender segments RcvBuffer buffered data
 RcvBuffer size set via
socket options (typical rwnd free buffer space
default is 4096 bytes)
 many operating systems
autoadjust RcvBuffer
TCP segment payloads
 sender limits amount of
unacked (“in-flight”)
data to receiver’s rwnd receiver-side buffering
value
 guarantees receive
buffer will not overflow
Transport Layer 3-66
Chapter 3 outline
3.1 transport-layer 3.5 connection-
services oriented transport:
3.2 multiplexing TCP
 segment structure
and
demultiplexing  reliable data transfer
 flow control
3.3 connectionless  connection
transport: UDP management
3.4 principles of 3.6 principles of
reliable data congestion control
transfer
3.7 TCP congestion
control
Transport Layer 3-67
 TCP 3-way handshake

client state server state

LISTEN LISTEN
choose init seq num, x
send TCP SYN msg
SYNSENT SYNbit=1, Seq=x
choose init seq num, y
send TCP SYNACK
msg, acking SYN SYN RCVD
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
received SYNACK(x)
ESTABindicates server is live;
send ACK for SYNACK;
this segment may contain ACKbit=1, ACKnum=y+1
client-to-server data
received ACK(y)
indicates client is live
ESTAB

Transport Layer 3-68

TCP: closing a connection
 client, server each close their side of
connection
 send TCP segment with FIN bit = 1
 respond to received FIN with ACK
 on receiving FIN, ACK can be combined with
own FIN
 simultaneous FIN exchanges can be
handled

Transport Layer 3-69

TCP: closing a connection
client state server state
ESTAB ESTAB
clientSocket.close()
FIN_WAIT_1 can no longer FINbit=1, seq=x
send but can
receive data CLOSE_WAIT
ACKbit=1; ACKnum=x+1
can still
FIN_WAIT_2 wait for server send data
close

LAST_ACK
FINbit=1, seq=y
TIMED_WAIT can no longer
send data
ACKbit=1; ACKnum=y+1
timed wait
for 2*max CLOSED
segment lifetime

CLOSED

Transport Layer 3-70

Chapter 3 outline
3.1 transport-layer 3.5 connection-
services oriented transport:
3.2 multiplexing TCP
 segment structure
and
demultiplexing  reliable data transfer
 flow control
3.3 connectionless  connection
transport: UDP management
3.4 principles of 3.6 principles of
reliable data congestion control
transfer
3.7 TCP congestion
control
Transport Layer 3-71
Principles of congestion
control
congestion:
 informally: “too many sources sending
too much data too fast for network to
handle”
 different from flow control!
 manifestations:
 lost packets (buffer overflow at
routers)
 long delays (queueing in router
buffers)
 a top-10 problem!
Transport Layer 3-72
Approaches towards congestion
control
two broad approaches towards congestion control:

end-end network-assisted
congestion congestion
control: control:
 no explicit  routers/switches
feedback from provide feedback to
network end systems
 congestion  single bit indicating
inferred from end- congestion (SNA,
system observed DECbit, TCP/IP
loss, delay ECN, ATM)
 approach taken by  explicit rate for
TCP sender to send at
Transport Layer 3-73
Chapter 3 outline
3.1 transport-layer 3.5 connection-
services oriented transport:
3.2 multiplexing TCP
 segment structure
and
demultiplexing  reliable data transfer
 flow control
3.3 connectionless  connection
transport: UDP management
3.4 principles of 3.6 principles of
reliable data congestion control
transfer
3.7 TCP congestion
control
Transport Layer 3-74
 TCP congestion control: additive
increase multiplicative decrease
 approach: sender increases transmission rate (window size),
probing for usable bandwidth, until loss occurs
 additive increase: increase cwnd by 1 MSS every RTT until
loss detected
 multiplicative decrease: cut cwnd in half after loss

additively increase window size …

…. until loss occurs (then cut window in half)
congestion window size
cwnd: TCP sender

AIMD saw tooth

behavior: probing
for bandwidth

time
Transport Layer 3-75
TCP Slow Start
Host A Host B
 when connection
begins, increase
rate exponentially one s e gm
ent
until first loss event:

RTT
 initially cwnd = 1 MSS two segm
en ts
 double cwnd every
RTT
 done by incrementing four segm
ents
cwnd for every ACK
received
 summary: initial rate
is slow but ramps up time
exponentially fast
Transport Layer 3-76
 TCP: detecting, reacting to
loss
 loss indicated by timeout:
 cwnd set to 1 MSS;
 window then grows exponentially (as in slow start) to threshold,
then grows linearly
 loss indicated by 3 duplicate ACKs: TCP RENO
 dup ACKs indicate network capable of delivering some segments
 cwnd is cut in half window then grows linearly
 TCP Tahoe always sets cwnd to 1 (timeout or 3 duplicate acks)

Transport Layer 3-77