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,

Computer
and delete slides (including this one) and slide content to suit your needs.
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
Networking: A
(after all, we’d like people to use our book!)
 If you post any slides on a www site, that you note that they are adapted
Top Down
from (or perhaps identical to) our slides, and note our copyright of this
material.
Approach
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  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 flow/congestion
• congestion control
control

Transport Layer 3-2

Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
• segment structure
3.2 multiplexing • reliable data transfer
and • flow control
demultiplexing • connection
3.3 connectionless management
transport: UDP 3.6 principles of
congestion control
3.4 principles of
3.7 TCP congestion
reliable data control
transfer 3.8 Evolution of transport-
layer functionality

Transport Layer 3-3

Transport services and
protocols applicatio

 provide logical n
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 (MTU),

po
passes to 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 =
between letters in envelopes
 transport protocol =
processes Ann and Bill who
• relies on, demux to in-house
enhances, siblings
network layer  network-layer protocol
services = postal service

Transport Layer 3-5

Internet transport-layer
protocols
 reliable, in-order applicatio
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
data link
• connection setup

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
 services not
physical
data link
physical

available:
• delay guarantees
• bandwidth
guarantees Transport Layer 3-6
Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
• segment structure
3.2 multiplexing • reliable data transfer
and • flow control
demultiplexing • connection
3.3 connectionless management
transport: UDP 3.6 principles of
congestion control
3.4 principles of
3.7 TCP congestion
reliable data control
transfer 3.8 Evolution of transport-
layer functionality

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 P4
transport process
transport network transport
network link network
link physical link
physical physical

Transport Layer 3-8

 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
application 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-9
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-10

Connectionless
demultiplexing
 recall: created socket  recall: when creating
has host-local port #: datagram to send
DatagramSocket mySocket1
= new
into UDP socket, must
DatagramSocket(12534); specify
• destination IP address
• destination port #
 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-11
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-12
Connection-oriented
demux
 TCP socket  server host may
identified by 4- support many
tuple: simultaneous TCP
• source IP address sockets:
• • each socket identified
source port number
by its own 4-tuple
• dest IP address  web servers have
• dest port number 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-13
 Connection-oriented demux:
example
application
application 80 P4 application
9157 P5 P6
P3 577 P2 P3 915
transport 5 7
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-14
 Connection-oriented demux:
example
threaded server (Select, Poll, ePoll, Libev, Libhv? Asyn I/O

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

Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
• segment structure
3.2 multiplexing • reliable data transfer
and • flow control
demultiplexing • connection
3.3 connectionless management
transport: UDP 3.6 principles of
congestion control
3.4 principles of
3.7 TCP congestion
reliable data control
transfer 3.8 Evolution of transport-
layer functionality

Transport Layer 3-16

UDP: User Datagram Protocol
[RFC 768]
 “no frills,” “bare bones”  UDP use:
Internet transport  streaming multimedia
protocol apps (loss tolerant,
 “best effort” service, rate sensitive)
UDP segments may be:  DNS
• lost
 SNMP
• delivered out-of-order
to app  reliable transfer over
 connectionless: UDP:
• no handshaking  add reliability at
between UDP sender, application layer
receiver  application-specific
• each UDP segment error recovery!
handled
independently of  Check opensource
others KCP, RUDP,. …
(term project !)
Transport Layer 3-17
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-18

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: addition (one checksum equals
checksum field value:
’s complement sum) of
segment contents • NO - error detected
 sender puts checksum • YES - no error detected.
value into UDP But maybe errors
checksum field nonetheless? More
later ….

Transport Layer 3-19

 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
* Check out the online interactive exercises for more
examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Transport Layer 3-20
Reliable UDP protocols
 UDT (UDP-based Reliable Data
Transfer Library)
 RUDP
 uTP (bit-torrent)
 KCP
 FEC: LongHair, ShortHair, WildHair
(gaming)

Transport Layer 3-21

UDP Lite
 allows a potentially damaged data payload to
be delivered to an application rather than
being discarded by the receiving station.
 using partial checksums that only covers part
of a datagram (an arbitrary count of octets at
the beginning of the packet), and will therefore
deliver packets that have been partially
corrupted.
 for multimedia protocols, such as VoIP or
streamed video
• resilience features
 Linux kernel version 2.6.20
int fd = socket(PF_INET, SOCK_DGRAM, IPPROTO_UDPLITE);
int val = 20; /* 8 octets of header + 12 octets of the application protocol. */
(void)setsockopt(fd, SOL_UDPLITE, UDPLITE_SEND_CSCOV, &val, sizeof val);

Transport Layer 3-22

Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
• segment structure
3.2 multiplexing • reliable data transfer
and • flow control
demultiplexing • connection
3.3 connectionless management
transport: UDP 3.6 principles of
congestion control
3.4 principles of
3.7 TCP congestion
reliable data control
transfer 3.8 Evolution of transport-
layer functionality

Transport Layer 3-23

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

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

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

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

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

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

Transport Layer 3-30

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

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

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

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

 rdt2.0 has a fatal flaw!
handling duplicates:
what happens if  sender retransmits current
ACK/NAK pkt if ACK/NAK corrupted
corrupted?  sender adds sequence
 sender doesn’t know number to each pkt
what happened at
receiver!
 receiver discards (doesn’t
deliver up) duplicate pkt
 can’t just retransmit:
possible duplicate
stop and wait
Bit error occurs sender sends one
anywhere and anytime ! packet,
then waits for
receiver
response Transport Layer 3-35
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-36

 rdt2.1: receiver, handles garbled
ACK/NAKs
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
0
&& has_seq (rcvpkt)

extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)

rdt_rcv(rcvpkt) && corrupt(rcvpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt)

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

Wait for Wait for

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

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

 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(ACK, 1, chksum)
udt_send(sndpkt)

Transport Layer 3-40

rdt3.0: channels with errors and
loss
new assumption: approach: sender waits
underlying “reasonable” amount of
channel can also time for ACK
lose packets  retransmits if no ACK
received in this time period
(data, ACKs)  if pkt (or ACK) just delayed
• checksum, seq. #, (not lost):
ACKs, • retransmission will be
retransmissions duplicated, but seq. #’s
will be of help … already handles this
• receiver must specify seq
but not enough
# of pkt being ACKed
 Requires
countdown timer(s)
Transport Layer 3-41
 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) 
Rx delayed pkt  Wait for Wait for
call 0 from ACK0 timeout
above udt_send(sndpkt)
start_timer
rdt_rcv(rcvpkt) reTx by
&& notcorrupt(rcvpkt) timeout
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)
reTx by rdt_send(data) 
rdt_rcv(rcvpkt) && Rx delayed pkt
timeout ( corrupt(rcvpkt) || sndpkt = make_pkt(1, data, checksum)
isACK(rcvpkt,0) ) udt_send(sndpkt)
start_timer

Transport Layer 3-42

 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-43
 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 pkt1 rcv ack1 pkt0 (detect duplicate)
send pkt0 ack1 send ack1
(detect duplicate)
ack1 send ack1 rcv pkt0
rcv ack1,skip ack0
rcv ack1 send ack0
send pkt0 pkt0 rcv ack0 pkt1
rcv pkt0 send pkt1 rcv pkt1
ack0 send ack0 ack1 send ack1

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

Transport Layer 3-44

Abnormal Situation in
rdt3.0
SENDER RECEIVER

Tx Pkt0 Pkt0
Rx Pkt0
reTx Pkt0 timeout Pkt0

ACK0
Tx Pkt1 Pkt1
Rx Pkt1
ACK1
Tx new Pkt0 Pkt0
Miss new Pkt0

Tx new Pkt1 Pkt1

K0
AC

Drop & Miss new Pkt1

ACK1
Tx new new Pkt0 Pkt0
Rx new new Pkt0

Out of sync Transport Layer 3-45

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

U L/R .008
sender = = = 0.00027
RTT + L / R 30.008
 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-46

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

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

 two generic forms of pipelined protocols:

go-Back-N, selective repeat
Transport Layer 3-48
 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-49

Pipelined protocols:
overview
Go-back-N: Selective Repeat:
 sender can have  sender can have up to N
up to N unacked unack’ed packets in
packets in pipeline pipeline
 receiver only sends  rcvr sends individual
cumulative ack ack for each packet
• doesn’t ack packet
if there’s a gap
 sender has one  sender maintains N
timer for oldest timers,
timers one timer for
unacked packet each unacked packet
• when timer expires, • when timer expires,
retransmit all retransmit only that
unacked packets unacked packet
https://www2.tkn.tu-berlin.de/teaching/rn/
animations/gbn_sr/ Transport Layer 3-50
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

PhD. Qualify in NTU ! Transport Layer 3-51

GBN: sender extended FSM
rdt_send(data)

if (nextseqnum < base+N) {

sndpkt[nextseqnum] = make_pkt(nextseqnum,data,chksum)
udt_send(sndpkt[nextseqnum])
if (base == nextseqnum)
start_timer
nextseqnum++
}
else
refuse_data(data)


base=1
nextseqnum=1
timeout
start_timer
Wait
udt_send(sndpkt[base])
udt_send(sndpkt[base+1])
rdt_rcv(rcvpkt) …
udt_send(sndpkt[nextseqnum-1])
&& corrupt(rcvpkt)


rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
base = getacknum(rcvpkt)+1
If (base == nextseqnum)
stop_timer
else
start_timer

Transport Layer 3-52

 GBN: receiver extended
FSM default

udt_send(sndpkt) rdt_rcv(rcvpkt)
&& notcurrupt(rcvpkt)
&& hasseqnum(rcvpkt,expectedseqnum)

Wait
extract(rcvpkt,data)
expectedseqnum=1 deliver_data(data)
sndpkt = make_pkt(expectedseqnum-1, sndpkt = make_pkt(expectedseqnum,ACK,chksum)
udt_send(sndpkt)
ACK,chksum) expectedseqnum++

rdt_rcv(rcvpkt)
&& notcurrupt(rcvpkt)
&& hasseqnum(rcvpkt,not_expectedseqnum)
udt_send(sndpkt)

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!
• re-ACK pkt with highest in-order seq # Transport Layer 3-53
 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-54

Selective repeat
 receiver individually acknowledges all
correctly received pkts
• buffers pkts,
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-55

Selective repeat: sender, receiver
windows

Transport Layer 3-56

Selective repeat
sender receiver
data from above: pkt n in [rcvbase,
 if next available seq # rcvbase+N-1]

in window, send pkt  send ACK(n)

 out-of-order: buffer
timeout(n):
 in-order: deliver (also
 resend pkt n, restart
deliver buffered, in-
timer order pkts), advance
ACK(n) in window to next not-
[sendbase,sendbase+N-1]: yet-received pkt
 mark pkt n as received
pkt n in [rcvbase-
 if n is smallest N,rcvbase-1]
unACKed pkt, advance  ACK(n)
window base to next
unACKed seq # otherwise:
 ignore
Transport Layer 3-57
 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 arrives?

Transport Layer 3-58

 sender window receiver window
Selective repeat: (after receipt) (after receipt)

dilemma 0123012 pkt0

pkt1 0123012
0123012
0123012 pkt2 0123012
example: 0123012
pkt3
 seq #’s: 0, 1, 2, 3 0123012
X
0123012
 window size=3 pkt0 will accept packet
with seq number 0
 receiver sees no (a) no problem

difference in two receiver can’t see sender side.

scenarios! receiver behavior identical in both cases!
something’s (very) wrong!
Ambiguous:
MuLan ?! pkt0
0123012
 duplicate data 0123012 pkt1 0123012
accepted as new in 0123012 pkt2 0123012
(b) X 0123012

timeout
X
retransmit pkt0 X
Q: what 0123012 pkt0
will accept packet
relationship (b) oops!
with seq number 0

between seq # Transport Layer 3-59

Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
• segment structure
3.2 multiplexing • reliable data transfer
and • flow control
demultiplexing • connection
3.3 connectionless management
transport: UDP 3.6 principles of
congestion control
3.4 principles of
3.7 TCP congestion
reliable data control
transfer 3.8 Evolution of transport-
layer functionality

Transport Layer 3-60

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
 reliable, in-order • MSS:
MSS maximum
segment size
byte steam:  connection-oriented:
• no “message • handshaking
boundaries” (exchange of control
 pipelined: msgs) inits sender,
receiver state before
• TCP congestion and data exchange
flow control set  flow controlled:
window size
• sender will not
 send & receive overwhelm receiver
buffers
Transport Layer 3-61
 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 piggyback
checksum (variable length)
(as in UDP)

Transport Layer 3-62

TCP seq. numbers, ACKs
outgoing segment from sender
sequence numbers: source port # dest port #
sequence number
• byte stream “number” acknowledgement number
of first byte in rwnd
segment’s data checksum urg pointer

acknowledgements: window size

N
• seq # of next byte
expected from other
side sender sequence number space
• cumulative ACK
• one timer sent
ACKed
sent, not- usable not
yet but not usable
Q: how receiver handles ACKed yet sent
(“in-flight
out-of-order segments ”)
incoming segment to sender
• A: TCP spec doesn’t source port # dest port #
say, - up to sequence number
implementor acknowledgement number
A rwnd
checksum urg pointer

Transport Layer 3-63

TCP seq. numbers, ACKs
Host A Host B

User
types
‘C’
Seq=42, ACK=79, data = ‘C’
host ACKs
receipt of
‘C’, echoes
Seq=79, ACK=43, data = ‘C’ back ‘C’
host ACKs
receipt
of echoed
‘C’ Seq=43, ACK=80

simple telnet scenario time

Transport Layer 3-64

TCP round trip time,
timeout
Q: how to set TCP Q: how to estimate
timeout value? RTT?
 longer than RTT  SampleRTT: measured
time from segment
• but RTT varies transmission until ACK
 too short: receipt
premature • ignore retransmissions
 SampleRTT will vary,
timeout,
want estimated RTT
unnecessary “smoother”
retransmissions • average several
 too long: slow recent measurements,
reaction to Movingnot just current
Average Method
SampleRTT
segment loss
Ex. Stock (per month/quarter/half-year/year
Transport Layer 3-65
 TCP round trip time,
timeout
EstimatedRTT(t+1) = (1-)*EstimatedRTT(t) + *SampleRTT(t)
 exponential weighted moving average (EWMA)
 influence of past sample decreases exponentially fast
 typical value:  = 0.125
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

350

RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

300
(milliseconds)
RTT

250
RTT (milliseconds)

200

sampleRTT
150

EstimatedRTT

100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
time Transport Layer 3-66
SampleRTT Estimated RTT
 TCP round trip time,
timeout
 timeout interval: EstimatedRTT plus “safety
margin”
• large variation in EstimatedRTT -> larger safety margin
 estimate SampleRTT deviation from EstimatedRTT:
DevRTT = (1-)*DevRTT +
*|SampleRTT-EstimatedRTT|
(typically,  = 0.25)

TimeoutInterval = EstimatedRTT + 4*DevRTT

estimated RTT “safety margin”

* Check out the online interactive exercises for more

examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Transport Layer 3-67
Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
• segment structure
3.2 multiplexing • reliable data transfer
and • flow control
demultiplexing • connection
3.3 connectionless management
transport: UDP 3.6 principles of
congestion control
3.4 principles of
3.7 TCP congestion
reliable data control
transfer 3.8 Evolution of transport-
layer functionality

Transport Layer 3-68

TCP reliable data transfer
 TCP creates rdt service
on top of IP’s unreliable
service
• pipelined segments
let’s initially consider
• cumulative acks (GBN- simplified TCP
based)
sender:
• single retransmission • ignore duplicate acks
timer (GBN-based)
• ignore flow control,
 retransmissions congestion control
triggered by:
• timeout events
• duplicate acks (new
idea!!!)
Transport Layer 3-69
TCP sender events:
data rcvd from app: timeout:
 create segment  retransmit segment
with seq # (SR-based) that
 seq # is byte- caused timeout
 restart timer
stream number of
first data byte in ack rcvd:
segment  if ack acknowledges
 start timer if not previously unacked
segments
already running • update what is known
• think of timer as for to be ACKed
oldest unacked • start timer if there are
segment still unacked
• expiration interval: segments
TimeOutInterval
Transport Layer 3-70
TCP sender (simplified)
data received from application above
create segment, seq. #: NextSeqNum
pass segment to IP (i.e., “send”)
NextSeqNum = NextSeqNum + length(data)
if (timer currently not running)
 start timer
NextSeqNum = InitialSeqNum wait
SendBase = InitialSeqNum for
event timeout
retransmit not-yet-acked
segment with
smallest seq. #
ACK received, with ACK field value y start timer

if (y > SendBase) {
SendBase = y
/* SendBase–1: last cumulatively ACKed byte */
if (there are currently not-yet-acked segments)
start timer
else
stop timer Transport Layer 3-71
}
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum

loop (forever) {
TCP
switch(event)
sender
event: data received from application above
create TCP segment with sequence number NextSeqNum (simplified
if (timer currently not running)
start timer
)
pass segment to IP
Comment:
NextSeqNum = NextSeqNum + length(data)
• SendBase-1: last
event: timer timeout cumulatively
retransmit not-yet-acknowledged segment with ack’ed byte
smallest sequence number (not GBN) Example:
start timer • SendBase-1 = 71;
y= 73, so the rcvr
event: ACK received, with ACK field value of y wants 73+ ;
if (y > SendBase) {
y > SendBase, so
SendBase = y
if (there are currently not-yet-acknowledged segments)
that new data is
start timer acked
else
stop timer
} /*check here !!!*/
} /* end of loop forever */ Transport Layer 3-72
 TCP: retransmission scenarios
Host A Host B Host A Host B

Seq=9 Seq=9
2 , 8 by 2 , 8 by
t e s da t e s da

Seq=92 timeout
ta Seq= ta
100,
20 by
te s dat
timeout

a
CK=
100
A
00
X K =1 120
C
A AC K =
loss
Seq=9 Seq=9
2 , 8 by 2 , 8 by
t es d a Sendbase t e s da
ta
ta

Seq=92 timeout
= 100
SendBase
= 120 K =12
0
=100 AC
A CK

SendBase
= 100 SendBase
= 120 premature timeout
time time
lost ACK scenario
Transport Layer 3-73
 TCP retransmission scenarios
(more)
Host A Host B

Seq=9
2, 8 b
y tes d
at a

=100
timeout

Seq=1 A C K
0 0, 20
by t e s
d at a
X
loss

SendBase CK =120
A
= 120

time
Cumulative ACK scenario

Transport Layer 3-74

TCP ACK generation [RFC 1122, RFC
2581]

Event at Receiver TCP Receiver action

Arrival of in-order segment with Delayed ACK.
ACK Wait up to 500ms
expected seq #. All data up to for next segment. If no next segment,
expected seq # already ACKed send ACK

Arrival of in-order segment with Immediately send single cumulative

expected seq #. One other ACK, ACKing both in-order segments
segment has ACK pending

Arrival of out-of-order segment Immediately send duplicate ACK,

ACK
higher-than-expect seq. # . indicating seq. # of next expected byte
Gap detected

Arrival of segment that Immediate send normal ACK,

ACK provided
partially or completely fills gap that segment starts at lower end of gap

Transport Layer 3-75

TCP Nagle's Algorithm

tinygram

tinygram

Check:
TCP_NODELAY in
waiting for Packing waiting for ACKing setsockopt()
Transport Layer 3-76
TCP fast retransmit (Fast
Recovery)
 time-out period
often relatively long: TCP fast retransmit
• long delay before
resending lost packet if sender receives
 detect lost segments N ACKs for same
via duplicate ACKs. data
(“triple duplicate ACKs”),

• sender often sends (“triple duplicate

many segments ACKs”), resend
back-to-back unacked segment
• if segment is lost, with smallest seq #
there will likely be  likely that unacked
many duplicate ACKs.
segment lost, so
don’t wait for
Chinese Fork :
timeout
How many persons (N) will
convince you that “Tiger is Coming” Transport
? Layer 3-77
 Fast retransmit algorithm:
event: ACK received, with ACK field value of y
if (y > SendBase) {
SendBase = y
if (there are currently not-yet-acknowledged segments)
start timer
else
stop timer
}
else {
increment count of dup ACKs received for y
if (count of dup ACKs received for y = 3) {
resend segment with sequence number y
}

a duplicate ACK for fast retransmit

already ACKed segment
Transport Layer 3-78
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-79
Selective
Acknowledgement (SACK)
 TCP resembles Go-Back-
N +--------+--------+--------+--------+
| Left Edge of 1st Block |
• But, it retransmits only +--------+--------+--------+--------+
one packet at a time, not | Right Edge of 1st Block |
the subsequent packets +--------+--------+--------+--------+
 TCP has an option of |
/ . . .
|
/
Selective | |
Acknowledgement +--------+--------+--------+--------+
| Left Edge of nth Block |
• Uses the optional fields in +--------+--------+--------+--------+
the TCP header | Right Edge of nth Block |
+--------+--------+--------+--------+
• Receiver indicates
consecutive blocks of
received, but out-of-order,
data
• With this option, TCP looks
like Selective Repeat
Transport Layer 3-80
TCP Header Options
 Maximum Segment Size (MSS)
 Window Scaling
• Original window size :16 bits (2^16=64KB)
• Window scaling value: 0-14, up to 2^(16+14)=1GB
 Selective Acknowledgements (SACK)
 Timestamps (check:RTSP)
• Use of timestamps are
• RTTM (Round Trip Time Measurement)
• PAWS (Protection against wrapped Sequence number)
 TCP Fast Open (TFO) Cookie
• avoid 3-way handshake, send GET directly
 Nop

Transport Layer 3-81

Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
• segment structure
3.2 multiplexing • reliable data transfer
and • flow control
demultiplexing • connection
3.3 connectionless management
transport: UDP 3.6 principles of
congestion control
3.4 principles of
3.7 TCP congestion
reliable data control
transfer 3.8 Evolution of transport-
layer functionality

Transport Layer 3-82

TCP flow control
application
application may process
Polling vs. callback
remove data from application
TCP socket buffers ….
TCP socket OS
receiver buffers
… slower than
TCP
receiver is TCP
delivering code
(sender is
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-83

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 87380 or 43689
bytes)
• many operating systems
autoadjust RcvBuffer TCP segment payloads
 sender limits amount of
unacked (“in-flight”) receiver-side buffering
data to receiver’s rwnd
value
 guarantees receive
buffer will not overflow Transport Layer 3-84
TCP Flow control: how it
works
 Rcvr advertises spare
room by including
value of RcvWindow in
segments
 Sender limits
unACKed data to
(Suppose TCP receiver RcvWindow
discards out-of-order • guarantees receive
segments) buffer doesn’t overflow
 spare room in buffer
= RcvWindow
= RcvBuffer-[LastByteRcvd -
LastByteRead]

Transport Layer 3-85

Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
• segment structure
3.2 multiplexing • reliable data transfer
and • flow control
demultiplexing • connection
3.3 connectionless management
transport: UDP 3.6 principles of
congestion control
3.4 principles of
3.7 TCP congestion
reliable data control
transfer 3.8 Evolution of transport-
layer functionality

Transport Layer 3-86

 Connection Management
before exchanging data, sender/receiver
“handshake”:
 agree to establish connection (each knowing the
other willing to establish connection)
 agree on connection parameters
application application

connection state: connection state:

ESTAB ESTAB
connection variables: connection Variables:
seq # client-to- seq # client-to-
server server
server-to-client server-to-
rcvBuffer size client
network
at server,client network
rcvBuffer size
at server,client

Socket clientSocket = Socket connectionSocket =

newSocket("hostname","port welcomeSocket.accept();
number");
Transport Layer 3-87
: what will happen if both hosts call newSocket() to connect each other simultaneously?
Agreeing to establish a
connection
2-way handshake:
Q: will 2-way handshake
always work in network?
 variable delays
Let’s talk  retransmitted messages
ESTAB (e.g. req_conn(x)) due to
OK message loss
ESTAB
 message reordering
 can’t “see” other side

choose x
req_conn(x)
ESTAB
acc_conn(x)
ESTAB

Transport Layer 3-88

 Agreeing to establish a
connection
2-way handshake failure scenarios:

choose x choose x
req_conn(x) req_conn(x)
ESTAB ESTAB
retransmit acc_conn(x) retransmit acc_conn(x)
req_conn( req_conn(
x) x)
ESTAB ESTAB
data(x+1) accept
req_conn(x)
retransmit data(x+1
data(x+1) )
connection connection
client x completes server x completes server
client
terminat forgets x terminat forgets x
es req_conn(x)
es

ESTAB ESTAB
data(x+1) accept
half open connection! data(x+1
(no client!) Phantom )
Transport Layer 3-89
!
TCP Connection Management
Recall: TCP sender, Three way
receiver establish
“connection” before handshake:
exchanging data Step 1: client host sends TCP
segments
SYN segment to server
 initialize TCP variables:
• specifies client initial seq #
• seq. #s
• no data
• buffers, flow control
info (e.g. RcvWindow) Step 2: server host receives SYN,
 client: connection initiator replies with SYNACK segment
Socket clientSocket = new • server allocates buffers
Socket("hostname","port • specifies server initial seq. #
number");
Step 3: client receives SYNACK,
 server: contacted by replies with ACK segment
client  which may contain data
Socket connectionSocket =
welcomeSocket.accept();

Transport Layer 3-90

TCP Connection Management (cont.)

= 1
ACK

half open
clien DoS
t_isn
+1
serv
e r_isn
+1

Transport Layer 3-91

 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)
ESTAB indicates server is live;
send ACK for SYNACK;
this segment may contain ACKbit=1, ACKnum=y+1
client-to-server data
Such as HTTP REQUEST may w/ HTTP REQUEST received ACK(y)
indicates client is live
Seq=x+1 ESTAB

Transport Layer 3-92

TCP 3-way
handshake: FSM
Create socket

Server closed Client

Bind port
Socket connectionSocket =
welcomeSocket.accept();

 Socket clientSocket =
Recv SYN(x) newSocket("hostname","port
number");
SYNACK(seq=y,ACKnum=x+1) x+1
create new socket for listen Send SYN(seq=x)
communication back to client

SYN SYN
rcvd sent

Recv SYNACK(seq=y,ACKnum=x+1)
x+1
ESTAB ACK(ACKnum=y+1)
y+1
Recv ACK(ACKnum=y+1)
y+1

Transport Layer 3-93
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-94

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

half 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-95

TCP Connection Management (cont.)

Closing a connection: client server

client closes socket: close

FIN
clientSocket.close();

Step 1: client end system

sends TCP FIN control ACK
close
segment to server FIN

Step 2: server receives

FIN, replies with ACK.

timed wait
ACK ACK
Closes connection, sends
FIN.
FIN

closed

Transport Layer 3-96

TCP Connection Management (cont.)

Step 3: client receives client server

FIN, replies with ACK.
ACK
closing
• Enters “timed wait” - FIN
will respond with ACK
to received FINs
ACK
closing
Step 4: server, receives
FIN
ACK. Connection closed.
Note: with small

timed wait
ACK
modification, can handle
simultaneous FINs. closed

closed

Transport Layer 3-97

TCP Connection Management
(cont)

TCP server
lifecycle

TCP client
lifecycle

Transport Layer 3-98

setsockopt(…SOL_xxx…)
TCP level : TCP_NODELAY

SOCKET level: SO_REUSEADDR SO_DEBUG

SO_REUSEPORT SO_BROADCAST
SO_OOBINLINE
SO_LINGER SO_DONTROUTE
SO_KEEPALIVE SO_RCVLOWAT
SO_SNDBUF SO_RCVTIMEO
SO_RCVBUF SO_SNDLOWAT
SO_SNDTIMEO
IP level: IP_MULTICAST_TTL
IP_MULTICAST_LOOP
IP_ADD_MEMBERSHIP
IP_DROP_MEMBERSHIP
https://pubs.opengroup.org/onlinepubs/00 Check: EAGAIN, EWOULDBLOCK
0095399/functions/setsockopt.html Transport Layer 3-99
Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
• segment structure
3.2 multiplexing • reliable data transfer
and • flow control
demultiplexing • connection
3.3 connectionless management
transport: UDP 3.6 principles of
congestion control
3.4 principles of
3.7 TCP congestion
reliable data control
transfer 3.8 Evolution of transport-
layer functionality

Transport Layer 3-100

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-101
Causes/costs of congestion:
scenario 1
original data: in
throughput:out
 two senders, two
receivers Host A
 one router, infinite unlimited shared
buffers output link buffers

 output link capacity: R

 no retransmission
Host B

R/2

delay
out

in R/2 in R/2

 maximum per-  large delays as arrival rate,
connection throughput: in, approaches capacity
R/2
Transport Layer 3-102
Causes/costs of congestion:
scenario 2
 one router, finite buffers
 sender retransmission of timed-out packet
• application-layer input = application-layer output:in
= out
‘
• transport-layer input includes retransmissions :in in

in : original data

'in: original data, plus out
retransmitted data

Host A

finite shared output link

Host B buffers
Transport Layer 3-103
Causes/costs of congestion:
scenario 2
idealization: perfect R/2
knowledge
 sender sends only when

out
router buffers available
in R/2

in : original data

copy 'in: original data, plus out
retransmitted data

A free buffer space!

finite shared output link

Host B buffers
Transport Layer 3-104
Causes/costs of congestion:
scenario 2
Idealization: known loss
packets can be lost, dropped
at router due to full buffers
 sender only resends if
packet known to be lost

in : original data

copy 'in: original data, plus out
retransmitted data

A
no buffer space!

Host B
Transport Layer 3-105
Causes/costs of congestion:
scenario 2
Idealization: known loss R/2
packets can be lost, when sending at R/2,
dropped at router due to some packets are

out
full buffers retransmissions but
asymptotic goodput
 sender only resends if is still R/2 (why?)
packet known to be lost in R/2

in : original data

'in: original data, plus out
retransmitted data

A
free buffer space!

Host B
Transport Layer 3-106
Causes/costs of congestion:
scenario 2
Realistic: duplicates R/2
 packets can be lost,
dropped at router due to when sending at R/2,
some packets are
full buffers

out
retransmissions
 sender times out including duplicated
that are delivered!
prematurely, sending in R/2
two copies, both of
which are delivered
in
copy
timeo
'in out
ut

A
free buffer space!

Host B
Transport Layer 3-107
Causes/costs of congestion:
scenario 2
Realistic: duplicates R/2
 packets can be lost,
dropped at router due when sending at R/2,
some packets are
to full buffers

out
retransmissions
 sender times out including duplicated
that are delivered!
prematurely, sending in R/2
two copies, both of
which are delivered
“costs” of congestion:
 more work (retrans) for given “goodput”
 unneeded retransmissions: link carries multiple copies of pkt
• decreasing goodput

Transport Layer 3-108

Causes/costs of congestion:
scenario 3
 four senders Q: what happens as in
 multihop paths and in’ increase ?
A: as red in’ increases, all arriving
 timeout/retransmit blue pkts at upper queue are
dropped, blue throughput  0
Host A
out
in : original data Host B

'in: original data, plus

retransmitted data
finite shared output link
buffers

Host D

Host C

Transport Layer 3-109

Causes/costs of congestion:
scenario 3
C/2
out

in’ C/2

another “cost” of congestion:

 when packet dropped, any “upstream transmission
capacity used for that packet was wasted!

Transport Layer 3-110

Causes/costs of congestion:
scenario 3

C/2
out

in’ C/2

Another “cost” of congestion:

 when packet dropped, any upstream transmission capacity
used for that packet was wasted!

Transport Layer 3-111

Approaches towards congestion
control
Two broad approaches towards congestion control:

End-end congestion Network-assisted

control: congestion control:
 no explicit feedback from  routers provide feedback
network to end systems
 congestion inferred from • single bit indicating
end-system observed congestion (SNA,
loss, delay DECbit, TCP/IP ECN,
 approach taken by TCP ATM)
• explicit rate sender
should send at

Transport Layer 3-112

Case study: ATM ABR congestion
control
ABR: available bit RM (resource
rate: management) cells:
 “elastic service”  sent by sender, interspersed
 if sender’s path with data cells
“underloaded”:  bits in RM cell set by
• sender should use switches (“network-
available bandwidth assisted”)
 if sender’s path • NI bit: no increase in rate
congested: (mild congestion)
• sender throttled to • CI bit: congestion
minimum indication
guaranteed rate  RM cells returned to sender
by receiver, with bits intact

Transport Layer 3-113

Case study: ATM ABR congestion
control

 two-byte ER (explicit rate) field in RM cell

• congested switch may lower ER value in cell
• sender’ send rate thus minimum supportable rate on
path
 EFCI bit in data cells: set to 1 in congested
switch
• if data cell preceding RM cell has EFCI set, sender sets
CI bit in returned RM cell
Transport Layer 3-114
Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
• segment structure
3.2 multiplexing • reliable data transfer
and • flow control
demultiplexing • connection
3.3 connectionless management
transport: UDP 3.6 principles of
congestion control
3.4 principles of
3.7 TCP congestion
reliable data control
transfer 3.8 Evolution of transport-
layer functionality

Transport Layer 3-115

CP congestion control
 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
additively increase window size …
after loss …. 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-116
TCP Congestion Control:
details
sender sequence number space
cwnd TCP sending rate:
 roughly: send
cwnd bytes, wait
last byte last byte RTT for ACKS,
ACKed sent, not- sent
yet then send more
ACKed
(“in-flight bytes cwnd
 sender limits
”) transmission: rate ~
~ bytes/sec
RTT
LastByteSent- < cwnd
LastByteAcked
 cwnd is dynamic, function of
perceived network congestion

Transport Layer 3-117

 TCP Congestion Control
 end-end control (no network How does sender
assistance) perceive congestion?
 sender limits transmission:  loss event =
LastByteSent-LastByteAcked timeout or 3
 CongWin duplicate Acks
 Roughly,  TCP sender reduces
CongWin rate (CongWin) after
rate = Bytes/sec loss event
RTT
 CongWin is dynamic, function of three mechanisms:
perceived network congestion • AIMD
• Slow start (SS)
• Congestion
Avoidance (CA)

Transport Layer 3-118

TCP AIMD
multiplicative additive increase: increase
decrease: cut CongWin by 1 MSS every
CongWin in half after RTT in the absence of
loss event loss events: probing
congestion
window

24 Kbytes

16 Kbytes

8 Kbytes

time

Long-lived TCP connection

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

RTT
• initially cwnd = 1 MSS
• double cwnd every RTT two segm
en ts
• done by incrementing
cwnd for every ACK
received four segm
 summary: initial rate is ents

slow but ramps up

exponentially fast

time

Transport Layer 3-120

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

TCP: Slow Start (SS) vs. Congestion
Avoidance (CA)
Q: when should the
exponential
increase switch to
linear?
A: when cwnd gets to
1/2 of its value
before timeout.

Implementation:
 variable ssthresh
 on loss event, ssthresh
is set to 1/2 of cwnd
just before loss event

* Check out the online interactive exercises for more

examples: http://gaia.cs.umass.edu/kurose_ross/interactive/ Transport Layer 3-122
Summary: TCP Congestion Control
 When CongWin is below Threshold, sender in
slow-start phase, window grows
exponentially.
 When CongWin is above Threshold, sender is
in congestion-avoidance phase, window
grows linearly.
 When a triple duplicate ACK occurs, Threshold
set to CongWin/2 and CongWin set to
Threshold.
 When timeout occurs, Threshold set to
CongWin/2 and CongWin is set to 1 MSS.

Transport Layer 3-123

TCP sender congestion
control
Event State TCP Sender Action Commentary
ACK receipt Slow Start CongWin = CongWin + MSS, Resulting in a doubling of
for previously (SS) If (CongWin > Threshold) CongWin every RTT
unacked set state to “Congestion
data Avoidance”
Exponential increase
ACK receipt Congestion CongWin = CongWin+MSS * Additive increase, resulting
for previously Avoidance (MSS/CongWin) in increase of CongWin by
unacked (CA) 1 MSS every RTT
data Linear increase
Loss event SS or CA Threshold = CongWin/2, Fast recovery,
recovery
detected by CongWin = Threshold, implementing multiplicative
triple Set state to “Congestion decrease. CongWin will not
duplicate Avoidance” drop below 1 MSS.
ACK
Timeout SS or CA Threshold = CongWin/2, Enter slow start
CongWin = 1 MSS,
Set state to “Slow Start”
Duplicate SS or CA Increment duplicate ACK count CongWin and Threshold
ACK for segment being acked not changed

(Reno:) Fast recovery : canceling of the slow start phase

after a triple duplicate ACK
Transport Layer 3-124
Summary: TCP Congestion
Control New
New ACK!
duplicate ACK
dupACKcount++
ACK!
new ACK
new ACK
.
cwnd = cwnd + MSS (MSS/cwnd)
dupACKcount = 0
cwnd = cwnd+MSS transmit new segment(s), as allowed
dupACKcount = 0
 transmit new segment(s), as allowed
cwnd = 1 MSS
ssthresh = 64 KB cwnd > ssthresh
dupACKcount = 0
slow  congestion
start timeout avoidance
ssthresh = cwnd/2
cwnd = 1 MSS duplicate ACK
timeout dupACKcount = 0 dupACKcount++
ssthresh = cwnd/2 retransmit missing segment
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment New
timeout
ACK!
ssthresh = cwnd/2
cwnd = 1 New ACK
dupACKcount = 0
retransmit missing segment cwnd = ssthresh dupACKcount == 3
dupACKcount == 3 dupACKcount = 0
ssthresh= cwnd/2 ssthresh= cwnd/2
cwnd = ssthresh + 3 cwnd = ssthresh + 3
retransmit missing segment retransmit missing segment
fast
recovery
duplicate ACK
cwnd = cwnd + MSS
transmit new segment(s), as allowed

Transport Layer 3-125

TCP throughput
 What’s the average throughout of TCP as
a function of window size and RTT?
• Ignore slow start
 Let W be the window size when loss
occurs.
 When window is W, throughput is W/RTT
 Just after loss, window drops to W/2,
throughput to W/2RTT.
 Average throughout: .75 W/RTT =
¾×W/RTT

Transport Layer 3-126

Average TCP Throughput

3 W
avg TCP thruput = bytes/sec
4 RTT

W/2

3-127

Transport Layer 3-127

TCP Futures
 Example: 1500 byte segments, 100ms RTT,
want 10 Gbps throughput
 Requires window size W = 83,333 in-flight
segments
 Throughput in terms
1.22 of
MSSloss rate: [Mathis
1997]:
RTT L

 ➜ L = 2·10-10 a very small loss rate ! Wow….

 New versions of TCP for high-speed needed!

Transport Layer 3-128

Question

Transport Layer 3-129

Answer

Transport Layer 3-130

Answer
-1

Transport Layer 3-131

TCP CUBIC
 Is there a better way than AIMD to “probe” for usable bandwidth?
 Insight/intuition:
• Wmax: sending rate at which congestion loss was detected
• congestion state of bottleneck link probably (?) hasn’t changed much
• after cutting rate/window in half on loss, initially ramp to to W max faster, but then
approach Wmax more slowly

Wmax classic TCP

TCP CUBIC - higher

Wmax/2
throughput in this
example

TCP CUBIC only changes the congestion avoidance phase.

Transport Layer: 3-132
TCP CUBIC
 K: point in time when TCP window size will reach Wmax
• K itself is tuneable
 increase W as a function of the cube of the distance between current
time and K
• larger increases when further away from K
• smaller increases (cautious) when nearer K
 TCP CUBIC default
Wmax
in Linux, most
TCP Reno
popular TCP for TCP CUBIC
popular Web TCP
sending
servers rate

time
t0 t1 t2 t3 t4

Transport Layer: 3-133

TCP and the congested “bottleneck
link”
 TCP (classic, CUBIC) increase TCP’s sending rate until packet loss occurs
at some router’s output: the bottleneck link

source destination
application application
TCP TCP
network network
link link
physical physical
packet queue almost
never empty, sometimes
overflows packet (loss)

bottleneck link (almost always busy)

Transport Layer: 3-134

TCP and the congested “bottleneck
link”
 TCP (classic, CUBIC) increase TCP’s sending rate until packet loss occurs
at some router’s output: the bottleneck link
 understanding congestion: useful to focus on congested bottleneck link

insight: increasing TCP sending rate will

source not increase end-end throughout
destination
with congested bottleneck
application application
TCP TCP
network network
link link
physical physical

insight: increasing TCP

sending rate will
increase measured RTT
Goal: “keep the end-end pipe just full, but not fuller”
RTT

Transport Layer: 3-135

TCP Vegas:
Delay-based TCP congestion control
Keeping sender-to-receiver pipe “just full enough, but no fuller”:
keep bottleneck link busy transmitting, but avoid high delays/buffering

# bytes sent in last

measured RTT interval
RTTmeasured throughput =
RTTmeasured
Delay-based approach:
RTTmin - minimum observed RTT (uncongested path)
uncongested throughput with congestion window cwnd is cwnd/RTTmin
if measured throughput “very close” to uncongested throughput
increase cwnd linearly /* since path not congested */
else if measured throughput “far below” uncongested throughout
decrease cwnd linearly /* since path is congested */

Transport Layer: 3-13

Delay-based TCP congestion control
 congestion control without inducing/forcing loss
 maximizing throughout (“keeping the just pipe full… ”) while keeping
delay low (“…but not fuller”)
 a number of deployed TCPs take a delay-based approach
 BBR deployed on Google’s (internal) backbone network

Transport Layer: 3-137

TCP Fairness
Fairness goal: if K TCP sessions share same
bottleneck link of bandwidth R, each should
have average rate of R/K

TCP connection 1

bottleneck
TCP
router
connection 2
capacity R

Transport Layer 3-138

Why is TCP fair?
Two competing sessions:
 Additive increase gives slope of 1, as throughout increases
 multiplicative decrease decreases throughput proportionally

R equal bandwidth share

Connection 2 throughput

loss: decrease window by factor of 2

congestion avoidance: additive increase
loss: decrease window by factor of 2
congestion avoidance: additive increase

starting
Connection 1 throughput R

Transport Layer 3-139

Fairness (more)
Fairness and UDP Fairness and parallel TCP
 Multimedia apps connections
often do not use TCP  nothing prevents app.
• do not want rate from opening parallel
throttled by connections between 2
congestion control hosts.
 Instead use UDP:  Web browsers do this
• pump audio/video at  Example: link of rate R
constant rate, tolerate
packet loss supporting 9
 Research area: TCP connections;
friendly (RFC 5348) • new app asks for 1 TCP,
gets rate R/10
• new app asks for 11 TCPs,
gets R/2 !

Exercise !!! Power Game!

Transport Layer 3-140
TFRC
 How to provide congestion control
without the reliability constrain

• TFRC (TCP Friendly Rate Control )

• Due to UDP traffic grows extremely, the TCP

traffic becomes victim.
• It is desired to have a new Rate Adaptive Rule
Protocol.
• The non-TCP Applications should not consume
resource.

Transport Layer 3-141

Explicit Congestion Notification
(ECN)
network-assisted congestion control:
 two bits in IP header (ToS field) marked by network
router to indicate congestion
 congestion indication carried to receiving host
 receiver (seeing congestion indication in IP
datagram) sets ECE bit on receiver-to-sender ACK
segment to notify sender of congestion

TCP ACK segment

source destination
application application
ECE=1
transport transport
network network
link link
physical physical

ECN=00 ECN=11

ECN=11
IP datagram
Transport Layer 3-142
Explicit Congestion Notification (RFC
3168)
CWR: Contention Window Reduction
ECE: Explicit Congestion Notification

Flag
Header Location Purpose
name

Congestion window
CWR TCP Bit 8
reduced

ECE TCP Bit 9 ECN Echo

ECT IP Bit 14 ECN Capable Transport

CE IP Bit 15 Congestion Experienced

Transport Layer 3-143

Delay modeling
Notation, assumptions:
Q: How long does it take  Assume one link between
to receive an object client and server of rate R
from a Web server after  S: MSS (bits)
sending a request?  O: object size (bits)
Ignoring congestion, delay  no retransmissions (no loss,
is influenced by: no corruption)
 TCP connection Window size:
establishment  First assume: fixed
 data transmission delay congestion window, W
segments
 slow start  Then dynamic window,
modeling slow start

Transport Layer 3-144

Fixed congestion window
(1)
First case:
WS/R > RTT + S/R: ACK
for first segment in
window returns before
window’s worth of
data sent

delay = 2RTT + O/R

Transport Layer 3-145

 Fixed congestion window
(2)
Second case:
 WS/R < RTT + S/R: wait
for ACK after sending
window’s worth of data
sent

delay = 2RTT + O/R

+ (K-1)[S/R + RTT - WS/R]

K is the number of windows that

cover the object. (O/(WS))
Transport Layer 3-146
TCP Delay Modeling: Slow Start (1)
Now suppose window grows according to slow
start
1+2+4+8+…+2p-1
It shows that the delay for one object is:
O  S S
Latency 2 RTT   P  RTT    ( 2 P  1)
R  R R

where P is the number of times TCP idles at server:

P min{Q, K  1}
- where Q is the number of times the server idles
if the object were of infinite size.

- and K is the number of windows that cover the

object.
Note : As K or Q increases → P increases
Transport Layer 3-147
 TCP Delay Modeling (3)
S
 RTT time from when server starts to send segment
R
until server receives acknowledgement
initiate TC P
connection
S
2k  1 time to transmit the kth window request
R object
first w indow
= S /R

S k1 S 
R TT

 R  RTT  2 idle time after the kth window second w indow

R 
= 2S /R

third w indow
= 4S /R

P
O
delay   2 RTT   idleTime p fourth w indow
= 8S /R
R p 1
P
O S S
  2 RTT   [  RTT  2 k  1 ]
R k 1 R R object
com plete
transm ission
delivered
O S S
  2 RTT  P[ RTT  ]  (2 P  1) tim e at
R R R tim e at
client
server

Transport Layer 3-148

 TCP Delay Modeling: Slow Start (2)
Delay components: initiate TC P
connection
• 2 RTT for connection
estab. and request request
object
• O/R to transmit object first w indow
= S /R
• time that server idles
due to slow start R TT
second w indow
= 2S /R

Server idles:
P = min{K-1,Q} times third w indow
= 4S /R

fourth w indow
Example: = 8S /R
• O/S = 15
segments
• K = 4 windows
•Q=2 object
com plete
transm ission
• P = min{K-1,Q} = delivered
tim e at
2 tim e at server
client

Server idles P=2 Transport Layer 3-149

TCP Delay Modeling (4)
Recall K = number of windows that cover object

How do we calculate K ?

K min{k : 20 S  21 S    2 k  1 S O}
min{k : 20  21    2 k  1 O / S }
k O
min{k : 2  1  }
S
O
min{k : k log 2 (  1)}
S
 O 
 log 2 (  1)
 S 

Calculation of Q, number of idles for infinite-size object,

is similar (see HW).
Transport Layer 3-150
HTTP Modeling
 Assume Web page consists of:
• 1 base HTML page (of size O bits)
• M images (each of size O bits)
 Non-persistent HTTP:
• M+1 TCP connections in series
• Response time = (M+1)O/R + (M+1)2RTT + sum of idle
times
 Persistent HTTP:
• 2 RTT to request and receive base HTML file
• 1 RTT to request and receive M images
• Response time = (M+1)O/R + 3RTT + sum of idle times
 Non-persistent HTTP with X parallel connections
• Suppose M/X integer.
• 1 TCP connection for base file
• M/X sets of parallel connections for images.
• Response time = (M+1)O/R + (M/X + 1)2RTT + sum of idle
times

Transport Layer 3-151

HTTP Response time (in seconds)
RTT = 100 msec, O = 5 Kbytes, M=10 and
X=5
20
18
16
14
non-persistent
12
10
persistent
8
6
4 parallel non-
persistent
2
0
28 100 1 10
Kbps Kbps Mbps Mbps

For low bandwidth, connection & response time dominated by

transmission time.
Persistent connections only give minor improvement over parallel
connections.
Transport Layer 3-152
HTTP Response time (in seconds)
RTT =1 sec, O = 5 Kbytes, M=10 and
X=5
70
60
50
non-persistent
40
30 persistent
20
parallel non-
10 persistent
0
28 100 1 10
Kbps Kbps Mbps Mbps

For larger RTT, response time dominated by TCP establishment

& slow start delays. Persistent connections now give important
improvement: particularly in high delaybandwidth networks.
Transport Layer 3-153
Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
• segment structure
3.2 multiplexing • reliable data transfer
and • flow control
demultiplexing • connection
3.3 connectionless management
transport: UDP 3.6 principles of
congestion control
3.4 principles of
3.7 TCP congestion
reliable data control
transfer 3.8 Evolution of transport-
layer functionality

Transport Layer 3-154

Evolving transport-layer
functionality
 TCP, UDP: principal transport protocols for 40 years
 different “flavors” of TCP developed, for specific
scenarios:
Scenario Challenges
Long, fat pipes (large data Many packets “in flight”; loss shuts down
transfers) pipeline
Wireless networks Loss due to noisy wireless links, mobility;
TCP treat this as congestion loss
Long-delay links Extremely long RTTs
Data center networks Latency sensitive
Background traffic flows Low priority, “background” TCP flows

 moving transport–layer functions to application layer, on top of UDP

•HTTP/3: QUIC
Transport Layer: 3-155
QUIC: Quick UDP Internet
Connections

 application-layer protocol, on top of UDP

• increase performance of HTTP
• deployed on many Google servers, apps (Chrome, mobile YouTube app)

HTTP/2 HTTP/2 (slimmed)

Application HTTP/3
TLS QUIC

Transport TCP UDP

Network IP IP

HTTP/2 over TCP HTTP/2 over QUIC over UDP

Transport Layer: 3-156

QUIC: Quick UDP Internet
Connections

adopts approaches we’ve studied in this chapter for

connection establishment, error control, congestion control
• error and congestion control: “Readers familiar with TCP’s loss detection
and congestion control will find algorithms here that parallel well-known
TCP ones.” [from QUIC specification]
• connection establishment: reliability, congestion control, authentication,
encryption, state established in one RTT

 multiple application-level “streams” multiplexed over

single QUIC connection
• separate reliable data transfer, security
• common congestion control
• like SCTP
Transport Layer: 3-157
QUIC: Connection establishment

TCP handshake
(transport layer) QUIC handshake

data
TLS handshake
(security)
data

TCP (reliability, congestion control QUIC: reliability, congestion control,

state) + TLS (authentication, crypto authentication, crypto state
state)
1 handshake
2 serial handshakes

Transport Layer: 3-158

 QUIC: streams: parallelism, no HOL
blocking
HTTP HTTP
GET GET HTTP
application

GET
HTTP HTTP
GET GET
HTTP
GET QUIC QUIC QUIC QUIC QUIC QUIC
encrypt encrypt encrypt encrypt encrypt encrypt
QUIC QUIC QUIC QUIC QUIC QUIC
TLS encryption TLS encryption RDT RDT RDT RDT
error!
RDT RDT

QUIC Cong. Cont. QUIC Cong. Cont.

transport

TCP RDT TCP

error! RDT

TCP Cong. Contr. TCP Cong. Contr. UDP UDP

(a) HTTP 1.1 (b) HTTP/2 with QUIC: no HOL blocking

Notice:
QUIC is application-layer protocol
QUIC congestion control is based on TCP NewReno [RFC 6582]Transport Layer: 3-159
Chapter 3: summary
 principles behind transport WELCOME to Internet
layer services:
next:
• multiplexing,
demultiplexing  leaving the
• reliable data transfer network “edge”
• flow control (application,
• congestion control transport layers)
 instantiation,  into the network
implementation in the “core”
Internet  two network
• UDP
• TCP
layer chapters:
• data plane
• control plane

Transport Layer 3-160

Homeworks
 P284, What are SYN  What are
flood attack, SYN  Datagram Congestion
cookies and TCP Cookie Control Protocol
Transactions (TCPCT) (DCCP)
(RFC7805)?  Stream Control
 P299, What is TCP Transmission Protocol
Splitting ? (SCTP)
 What is Multipath TCP  TCP-Friendly Rate
(MPTCP) (RFC6824)? Control (TFRC)
How does it work? What  Google BBR
are the rules of it? (Bottleneck Bandwidth
 Review Questions (6): and Round-trip
propagation time, BBR)
R3, R5, R6, R8, R11,
R19
 Problems (7): P3, P14,
P23, P25, P32, P37, P48 Transport Layer 3-161