Chapter_3_v8.0

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, 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 (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 from (or perhaps identical to) our slides, and note our
copyright of this material.
Computer Networking: A
For a revision history, see the slide note for this page.
Top-Down Approach
Thanks and enjoy! JFK/KWR 8th edition
Jim Kurose, Keith Ross
All material copyright 1996-2020
J.F Kurose and K.W. Ross, All Rights Reserved Pearson, 2020
Transport Layer: 3-1
Transport layer: overview
Our goal:
▪understand principles ▪learn about Internet transport
behind transport layer layer protocols:
services: • UDP: connectionless transport
• multiplexing, • TCP: connection-oriented reliable
demultiplexing transport
• reliable data transfer • TCP congestion control
• flow control
• congestion control

Transport layer: roadmap
▪Transport-layer services
▪Multiplexing and demultiplexing
▪Connectionless transport: UDP
▪Principles of reliable data transfer
▪Connection-oriented transport: TCP
▪Principles of congestion control
▪TCP congestion control
▪Evolution of transport-layer
functionality
Transport services and protocols
application
transport
▪provide logical communication mobile

network
network
data link
physical
between application processes national or global ISP
running on different hosts
log
ica
le
▪transport protocols actions in end
n d-
systems:
e nd
local or
tra
• sender: breaks application messages regional ISP
nsp
into segments, passes to network layer
ort
home network content
• receiver: reassembles segments into provider
network
messages, passes to application layer application
transport
datacenter
network
network
▪two transport protocols available to data link

physical
Internet applications enterprise

network
• TCP, UDP
Transport vs. network layer services and protocols
household analogy:
12 kids in Ann’s house sending
letters to 12 kids in Bill’s house:
▪hosts = houses
▪processes = kids
▪app messages = letters in
envelopes
▪transport protocol = Ann and Bill
who demux to in-house siblings
▪network-layer protocol = postal
service
Transport vs. network layer services and protocols
▪network layer: logical household analogy:

communication between 12 kids in Ann’s house sending
hosts letters to 12 kids in Bill’s house:
▪hosts = houses
▪transport layer: logical
▪processes = kids
communication between
▪app messages = letters in
processes envelopes
• relies on, enhances, network ▪transport protocol = Ann and Bill
layer services who demux to in-house siblings
▪network-layer protocol = postal
service
Transport Layer Actions
Sender:
application ▪ is passed an application- app. msg
application
layer message
transport
▪ determines segment TThtransport
h app. msg
header fields values
network (IP)
▪ creates segment network
▪ passes segment to IP (IP)
link
link
physical physical

Transport Layer Actions
Receiver:
application ▪ receives segment from IP application
▪ checks header values
app. msg
transport ▪ extracts application-layer transport
message
network (IP) ▪ demultiplexes message up network
to application via socket (IP)
link
link
physical physical
Th app. msg

Two principal Internet transport protocols
application
transport
▪TCP: Transmission Control Protocol mobile

network
network
data link
physical
national or global ISP
• reliable, in-order delivery
log
ica
le
• flow control
n d-
e nd
• connection setup local or
tra
regional ISP
▪UDP: User Datagram Protocol
nsp
ort
home network
• unreliable, unordered delivery content
provider
network
• no-frills extension of “best-effort” IP application
transport
datacenter
network
network
▪services not available: data link

physical
• delay guarantees enterprise

network
• bandwidth guarantees
Chapter 3: roadmap
functionality
HTTP server
client
application application
HTTP msg
transport
transport network transport

network link network
link physical link
physical physical

HTTP server
client
HTTP msg
Ht HTTP msg
transport

link physical link
physical physical

HTTP server
client
HTTP msg
Ht HTTP msg
transport
Hnnetwork
Ht HTTP msg
transport transport
link physical link
physical physical

HTTP server
client
transport

link physical link
physical physical
Hn Ht HTTP msg

HTTP server
client1 client2
P- P-
application client1 client2 application
transport

link physical link
physical physical

Multiplexing/demultiplexing
multiplexing at sender: demultiplexing at receiver:
handle data from multiple use header info to deliver
sockets, add transport header received segments to correct
(later used for demultiplexing) socket
application
application P1 P2 application sock

P3 transport P4 et
process
link physical link
physical physical

How demultiplexing works
▪host receives IP datagrams 32
bits
• each datagram has source IP source port dest port
address, destination IP address # #
• each datagram carries one other header

transport-layer segment fields
• each segment has source,
applicati
destination port number on
▪host uses IP addresses & port data
(payload
numbers to direct segment to )
appropriate socket TCP/UDP segment
format

Connectionless demultiplexing
Recall: when receiving host receives
▪when creating socket, must UDP segment:
specify host-local port #: • checks destination port # in
segment
DatagramSocket mySocket1
= new DatagramSocket(12534); • directs UDP segment to
socket with that port #
▪ when creating datagram to
send into UDP socket, must
IP/UDP datagrams with same dest.
specify port #, but different source IP
• destination IP address addresses and/or source port
• destination port # numbers will be directed to same
socket at receiving host
Connectionless demultiplexing: an example
DatagramSocket
serverSocket = new
DatagramSocket
DatagramSocket mySocket2 = DatagramSocket mySocket1 =
new DatagramSocket (6428); new DatagramSocket (5775);
(9157); application
application P application
P 1 P
3 4
transport
transport transport
network
link physical link
physical physical
source port: source port:

6428 ?
dest port: 9157 dest port: ?
source port: source port:

9157 ?
dest port: 6428 dest port: ?
Connection-oriented demultiplexing
▪TCP socket identified by ▪ server may support many
4-tuple: simultaneous TCP sockets:
• source IP address • each socket identified by its
• source port number own 4-tuple
• dest IP address • each socket associated with
• dest port number a different connecting client
▪demux: receiver uses all
four values (4-tuple) to
direct segment to
appropriate socket
Connection-oriented demultiplexing: example
application
application P P P application
P 4 5 6 P P
1 2 3
transport
transport transport
network
link physical link
physical server: physical
IP
address
B
host: IP source IP,port: host: IP
address B,80 source IP,port: address
A
dest IP,port: C,5775 C
A,9157 dest IP,port: B,80
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
Summary
▪ Multiplexing, demultiplexing: based on segment, datagram
header field values
▪ UDP: demultiplexing using destination port number (only)
▪ TCP: demultiplexing using 4-tuple: source and destination IP
addresses, and port numbers
▪ Multiplexing/demultiplexing happen at all layers

Chapter 3: roadmap
functionality
UDP: User Datagram Protocol
▪ “no frills,” “bare bones”
Why is there a UDP?
Internet transport protocol ▪ no connection
establishment (which can
▪ “best effort” service, UDP add RTT delay)
segments may be: ▪ simple: no connection state
• lost at sender, receiver
• delivered out-of-order to app ▪ small header size
▪ connectionless: ▪ no congestion control
▪ UDP can blast away as fast as
• no handshaking between UDP desired!
sender, receiver ▪ can function in the face of
• each UDP segment handled congestion
independently of others
UDP: User Datagram Protocol
▪ UDP use:
▪streaming multimedia apps (loss tolerant, rate sensitive)
▪DNS
▪SNMP
▪HTTP/3
▪ if reliable transfer needed over UDP (e.g., HTTP/3):
▪add needed reliability at application layer
▪add congestion control at application layer

UDP: User Datagram Protocol [RFC 768]

UDP: Transport Layer Actions
SNMP client SNMP server
transport transport
(UDP) (UDP)
network (IP) network

(IP)
link
link
physical physical


UDP sender actions:
application ▪ is passed an application- SNMP msg
application
layer message
transport ▪ determines UDP segment UDPtransport
UDPh h SNMP msg
(UDP) header fields values (UDP)
network (IP)
▪ creates UDP segment network
▪ passes segment to IP (IP)
link
link
physical physical


UDP receiver actions:
application ▪ receives segment from IP application
▪ checks UDP checksum
transport
transport
SNMP msg header value
(UDP) ▪ extracts application-layer (UDP)
UDP h SNMP (IP)

network msg message network
▪ demultiplexes message up (IP)
link to application via socket link
physical physical

UDP segment header
32
bits
source port dest port
# #
checksu
lengt
h m
applicati length, in bytes of

on UDP segment,
data including header
(payload
)
data to/from
UDP segment application layer
format

UDP checksum
Goal: detect errors (i.e., flipped bits) in transmitted segment
1st number 2nd number sum
Transmitted: 5 6 11
Received: 4 6 11
receiver-computed
checksum
= sender-computed
checksum (as received)

UDP checksum
Goal: detect errors (i.e., flipped bits) in transmitted segment
sender: receiver:
▪treat contents of UDP ▪compute checksum of received
segment (including UDP header segment
fields and IP addresses) as
sequence of 16-bit integers ▪check if computed checksum
▪checksum: addition (one’s equals checksum field value:
complement sum) of segment • Not equal - error detected
content • Equal - no error detected. But maybe
▪checksum value put into errors nonetheless? More later ….
UDP checksum field
Internet checksum: an example
example: add two 16-bit integers
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0
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 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 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: h ttp://gaia.cs.umass.edu/kurose_ross/interactive/
Internet checksum: weak protection!
example: add two 16-bit integers
0 1
1 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 1 0
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 Even though
numbers have
sum 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0 changed (bit
flips), no change
checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1 in checksum!

Summary: UDP
▪ “no frills” protocol:
• segments may be lost, delivered out of order
• best effort service: “send and hope for the best”
▪ UDP has its plusses:
• no setup/handshaking needed (no RTT incurred)
• can function when network service is compromised
• helps with reliability (checksum)
▪ build additional functionality on top of UDP in application layer
(e.g., HTTP/3)
Chapter 3: roadmap
functionality
Principles of reliable data transfer
sending receiving
process process
applicatio data data
ntranspor
t reliable
channel
reliable service abstraction

sending receiving sending receiving

process process process process
applicatio data data application data data
ntranspor transport
t reliable
channel
sender-side of receiver-side
reliable service abstraction reliable data of reliable data
transfer protocol transfer protocol
transport
network
unreliable channel
reliable service implementation

sending receiving
process process
application data data
transport
Complexity of reliable data reliable data
transfer protocol
of reliable data
transfer protocol
transfer protocol will depend
(strongly) on characteristics of transport
network
unreliable channel (lose, unreliable channel
corrupt, reorder data?)

sending receiving
process process
application data data
transport
reliable data of reliable data
Sender, receiver do not know transfer protocol transfer protocol
the “state” of each other, e.g.,
was a message received? transport
network
▪ unless communicated via a unreliable channel
message

Reliable data transfer protocol (rdt): interfaces
rdt_send(): called from above, deliver_data(): called by rdt
(e.g., by app.). Passed data to to deliver data to upper layer
deliver to receiver upper layer
sending receiving
process process
rdt_send() data data
deliver_data()
sender-side data receiver-side

implementation of implementation of
rdt reliable data packet rdt reliable data
transfer protocol transfer protocol
udt_send() Header data Header data rdt_rcv()
unreliable channel
udt_send(): called by rdt rdt_rcv(): called when packet
to transfer packet over Bi-directional communication over arrives on receiver side of
unreliable channel to receiver unreliable channel channel
Reliable data transfer: getting started
We will:
▪ incrementally develop sender, receiver sides of reliable data transfer
protocol (rdt)
▪ consider only unidirectional data transfer
• but control info will flow in both directions!
▪ use finite state machines (FSM) to specify sender, receiver
event causing state
transition
actions taken on state
state: when in this “state” transition
next state uniquely stat stat
determined by next e eve
event e
1 nt
action
2
s

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)

send call from packet = make_pkt(data) receiv call from extract (packet,data)
above udt_send(packet) below
er er deliver_data(data)

rdt2.0: channel with bit errors
▪ underlying channel may flip bits in packet
• checksum (e.g., Internet checksum) to detect bit errors
▪ the question: how to recover from errors?
How do humans recover from “errors” during conversation?

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
stop and wait

sender sends one packet, then waits for receiver response
rdt2.0: FSM specifications
rdt_send(data)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
Wait for Wait for isNAK(rcvpkt)
send call from ACK or udt_send(sndpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt)
er above NAK
udt_send(NAK)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

Wait for
Λ call from receiv
below
er
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)

rdt2.0: FSM specification
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
er above NAK
udt_send(NAK)

Wait for
Λ call from receiv
below
er
Note: “state” of receiver (did the receiver get my
message correctly?) isn’t known to sender unless
somehow communicated from receiver to sender deliver_data(data)
▪ that’s why we need a protocol! udt_send(ACK)

rdt2.0: operation with no errors
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
er above NAK
udt_send(NAK)

Wait for
Λ call from receiv
below
er
deliver_data(data)
udt_send(ACK)

rdt2.0: corrupted packet scenario
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
er above NAK
udt_send(NAK)

Wait for
Λ call from receiv
below
er
deliver_data(data)
udt_send(ACK)

rdt2.0 has a fatal flaw!
what happens if ACK/NAK handling duplicates:
corrupted? ▪sender retransmits current pkt if
▪sender doesn’t know what ACK/NAK corrupted
happened at receiver!
▪sender adds sequence number to
▪can’t just retransmit: possible each pkt
duplicate
▪receiver discards (doesn’t deliver
up) duplicate pkt
stop and wait
sender sends one packet, then
waits for receiver response
rdt2.1: sender, handling garbled ACK/NAKs
rdt_send(data)
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) ||
Wait for Wait for isNAK(rcvpkt) )
call 0 from ACK or
NAK 0 udt_send(sndpkt)
above
rdt_rcv(rcvpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) &&
&& notcorrupt(rcvpkt)
isACK(rcvpkt)
&& isACK(rcvpkt)
Λ
Λ
Wait for Wait for
ACK or call 1 from
rdt_rcv(rcvpkt) NAK 1 above
&& (corrupt(rcvpkt) ||
isNAK(rcvpkt) ) rdt_send(data)
udt_send(sndpkt) sndpkt = make_pkt(1, data, checksum)

udt_send(sndpkt)

rdt2.1: receiver, handling garbled ACK/NAKs
&& has_seq0(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && rdt_rcv(rcvpkt) &&
(corrupt(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)
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)

rdt2.1: discussion
sender: receiver:
▪seq # added to pkt ▪must check if received packet
▪two seq. #s (0,1) will suffice. is duplicate
Why? • state indicates whether 0 or 1 is
expected pkt seq #
▪must check if received ACK/NAK
▪note: receiver can not know if
corrupted
its last ACK/NAK received OK
▪twice as many states at sender
• state must “remember” whether
“expected” pkt should have seq #
of 0 or 1

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
As we will see, TCP uses this approach to be NAK-free

rdt2.2: sender, receiver fragments
rdt_send(data)
udt_send(sndpkt) rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
Wait for Wait for
ACK isACK(rcvpkt,1) )
call 0 from
above 0 udt_send(sndpkt)
sender
FSM rdt_rcv(rcvpkt)
fragment && notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && && isACK(rcvpkt,0)
(corrupt(rcvpkt) || Λ
has_seq1(rcvpkt)) Wait for receiver
0 from
udt_send(sndpkt) below FSM
fragment
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt) Transport Layer: 3-55
rdt3.0: channels with errors and loss
New channel assumption: underlying channel can also lose
packets (data, ACKs)
• checksum, sequence #s, ACKs, retransmissions will be of help …
but not quite enough
Q: How do humans handle lost sender-to-

receiver words in conversation?

rdt3.0: channels with errors and loss
Approach: sender waits “reasonable” amount of time for ACK
▪ retransmits if no ACK received in this time
▪ if pkt (or ACK) just delayed (not lost):
• retransmission will be duplicate, but seq #s already handles this!
• receiver must specify seq # of packet being ACKed
▪ use countdown timer to interrupt after “reasonable” amount of
time
timeo
ut

rdt3.0 sender
rdt_send(data)
udt_send(sndpkt)
start_timer
Wait for Wait

call 0 from for
above ACK0
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
stop_timer && isACK(rcvpkt,0)
stop_timer
Wait Wait for
for call 1 from
ACK1 above
rdt_send(data)
udt_send(sndpkt)
start_timer

rdt3.0 sender
rdt_send(data)
rdt_rcv(rcvpkt) &&
sndpkt = make_pkt(0, data, checksum) ( corrupt(rcvpkt) ||
udt_send(sndpkt) isACK(rcvpkt,1) )
rdt_rcv(rcvpkt) start_timer Λ
Λ Wait for Wait
for timeout
call 0 from
ACK0 udt_send(sndpkt)
above
start_timer
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1) && notcorrupt(rcvpkt)
stop_timer && isACK(rcvpkt,0)
stop_timer
Wait Wait for
timeout for call 1 from
udt_send(sndpkt) ACK1 above
start_timer rdt_rcv(rcvpkt)
rdt_send(data) Λ
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) || udt_send(sndpkt)
isACK(rcvpkt,0) ) start_timer
Λ

rdt3.0 in action
send receiv send receiv
er er er
send er
send pkt0 pkt0
pkt0 rcv pkt0 rcv
ack0 send
pkt0 ack0 send
pkt0
rcv ack0 rcv ack0
send pkt1 send
ack0 pkt1
ack0 X
pkt1 rcv pkt1 los
ack1 send
pkt1 s
rcv ack1
send
ack1 pkt0
rcv timeout
pkt0 resend pkt1
ack0 send
pkt0 pkt1 rcv
ack0 ack1 send
pkt1
rcv ack1
send
ack1 pkt0
(a) no pkt0 rcv
ack send
pkt0
loss 0 ack0
(b) packet
loss Transport Layer: 3-60
rdt3.0 in action
send receiv
er
send er
send receiv pkt0
er er pkt0 rcv
send pkt0 send
pkt0
ack0
pkt0 rcv rcv ack0
ack0 send
pkt0 send
ack0 pkt1
rcv ack0 pkt1 rcv
send
ack0 pkt1 send
pkt1
pkt1 rcv ack1 ack1
ack1 send
X pkt1 timeout
los ack1 resend
s pkt1 pkt1 rcv
timeout
resend pkt1
rcv rcv pkt1
(detect
pkt1 send pkt0 send
duplicate)
(detect
pkt1 ack1
ack1 send
duplicate) pkt0 ack1 ack1
rcv
rcv rcv send
pkt0 ack1 (ignore ack0 pkt0
send
ack1 ack1 ack0
pkt0 rcv )
ack0 send
pkt0 pkt1
ack0
(c) ACK (d) premature timeout/ delayed

loss ACK Transport Layer: 3-61
Performance of rdt3.0 (stop-and-wait)
▪U sender: utilization – fraction of time sender busy sending
▪example: 1 Gbps link, 15 ms prop. delay, 8000 bit packet

• time to transmit packet into channel:
L 8000 bits
Dtrans = R = = 8 microsecs
109 bits/sec

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

RTT last packet bit arrives, send ACK
ACK arrives, send next

packet, t = RTT + L / R

rdt3.0: stop-and-wait operation
sender receiver
L/R L/R
Usender =
RTT + L / R
.008 RTT
=
30.008
= 0.00027
▪ rdt 3.0 protocol performance stinks!

▪ Protocol limits performance of underlying infrastructure (channel)

rdt3.0: pipelined protocols operation
pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged
packets
• range of sequence numbers must be increased
• buffering at sender and/or receiver

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!

Go-Back-N: sender
▪sender: “window” of up to N, consecutive transmitted but unACKed pkts
• k-bit seq # in pkt header
▪ cumulative ACK: ACK(n): ACKs all packets up to, including seq # n

• on receiving ACK(n): move window forward to begin at n+1
▪ timer for oldest in-flight packet
▪ timeout(n): retransmit packet n and all higher seq # packets in window
Go-Back-N: receiver
▪ ACK-only: always send ACK for correctly-received packet so far, with
highest in-order seq #
• may generate duplicate ACKs
• need only remember rcv_base
▪on receipt of out-of-order packet:
• can discard (don’t buffer) or buffer: an implementation decision
• re-ACK pkt with highest in-order seq #
Receiver view of sequence number space:
received and ACKed
… … Out-of-order: received but not ACKed
rcv_base
Not received
Go-Back-N in action
sender window send receiv
0 1 2 3 4(N=4)
5678 er
send er
012345678 pkt0
send receive pkt0, send
012345678
pkt1 X los ack0
012345678
send s receive pkt1, send
pkt2 ack1
012345678 rcv ack0,send
send
012345678 pkt4
rcv ack1, pkt3
send receive pkt3,
receive pkt4,
(wait)
pkt5 discard,
discard,
ignore duplicate (re)send ack1
receive(re)send
pkt5,
ACK
discard,
ack1
pkt 2
timeout (re)send
012345678 send
012345678 pkt2 ack1
012345678 send rcv pkt2, deliver, send
012345678 pkt3 ack2
send rcv pkt3, deliver, send
pkt4 ack3
send rcv pkt4, deliver, send
pkt5 ack4 Transport Layer: 3-69
Selective repeat
▪receiver individually acknowledges all correctly received
packets
• buffers packets, as needed, for eventual in-order delivery to upper
layer
▪sender times-out/retransmits individually for unACKed packets
• sender maintains timer for each unACKed pkt
▪sender window
• N consecutive seq #s
• limits seq #s of sent, unACKed packets

Selective repeat: sender, receiver windows

Selective repeat: sender and receiver
sender receiver
data from above: packet n in [rcvbase, rcvbase+N-1]
▪ if next available seq # in ▪ send ACK(n)
window, send packet ▪ out-of-order: buffer
timeout(n): ▪ in-order: deliver (also deliver
buffered, in-order packets),
▪ resend packet n, restart timer advance window to next not-yet-
ACK(n) in [sendbase,sendbase+N]: received packet
▪ mark packet n as received packet n in [rcvbase-N,rcvbase-1]
▪ ACK(n)
▪ if n smallest unACKed packet,
advance window base to next otherwise:
unACKed seq # ▪ ignore

Selective Repeat in action
sender window send receiv
0 1 2 3 4(N=4)
5678 er
send er
012345678 pkt0
012345678 send receive pkt0, send
012345678 pkt1 X los ack0
send s receive pkt1, send
pkt2 ack1
012345678 rcv ack0,send
send
012345678 pkt4
rcv ack1, pkt3
send receive pkt3, buffer,
receivesend
pkt4,ack3
(wait)
pkt5
record ack3 buffer,
arrived receivesend
pkt5,ack4
pkt 2 buffer,
012345678 timeout
send pkt2 send ack5
012345678 (but not
012345678 3,4,5) rcv pkt2; deliver pkt2,
012345678 pkt3, pkt4, pkt5; send
ack2
Q: what happens when ack2
arrives?
Selective repeat:
sender receiver
window window
(after (after receipt)
a dilemma!
receipt)
012301 pkt
2 0pkt
012301 012301
2 1
pkt 2
012301
012301
2 2 2
012301
example: 012301
2
pkt
3 X
2
012301
▪ seq #s: 0, 1, 2, 3 (base 4 counting) 2 pkt will accept
0 packet
▪ window size=3 (a) no with seq
number 0
problem
012301 pkt
2 0
pkt
012301 012301
2 1
pkt 2
012301 X 012301
2 2 X 2
012301
X 2
timeout
retransmit
pkt0
012301 pkt
2 0 will accept
packet
(b) with seq
number 0
oops! Transport Layer: 3-74
Selective repeat:
sender receiver
window window
(after (after receipt)
a dilemma!
receipt)
012301 pkt
2 0pkt
012301 012301
2 1
pkt 2
012301
012301
2 2 2
012301
example: 012301
2
pkt
3 X
2
▪ seq #s: 0, 1, 2, 3 (base 4 counting) ▪receiver can’t

012301
2 pkt will accept
see sender0side packet
▪ window size=3 (a) no
▪receiver with seq
number 0
problem
behavior
identical in both
cases!
▪0something’s
12301 pkt
2(very) wrong!
0
Q: what relationship is needed 012301
2
pkt
1
pkt
012301
2
X
between sequence # size and 012301 012301
2 2 X 2
012301
window size to avoid problem timeout
X 2
in scenario (b)? retransmit

pkt0
012301 pkt
2 0 will accept
packet
(b) with seq
number 0
oops! Transport Layer: 3-75
Chapter 3: roadmap
• segment structure
• reliable data transfer
• flow control
• connection management
TCP: overview RFCs: 793,1122, 2018, 5681, 7323
▪ point-to-point: ▪ cumulative ACKs
• one sender, one receiver ▪ pipelining:
▪ reliable, in-order byte • TCP congestion and flow control
steam: set window size
• no “message boundaries" ▪ connection-oriented:
▪ full duplex data: • handshaking (exchange of control
• bi-directional data flow in messages) initializes sender,
same connection receiver state before data exchange
• MSS: maximum segment size ▪ flow controlled:
• sender will not overwhelm receiver

TCP segment structure
32 bits
source port dest port segment seq #: counting

ACK: seq # of next expected #
sequence number# bytes of data into bytestream
byte; A bit: this is an ACK (not segments!)
acknowledgement number
length (of TCP header) head not
len used C EUAP R SF receive window flow control: # bytes
Internet checksum checksum Urg data pointer receiver willing to accept
options (variable
C, E: congestion notification length)
TCP options
application data sent by
RST, SYN, FIN: connection data application into
management (variable TCP socket
length)

TCP sequence numbers, ACKs
outgoing segment from
Sequence numbers: source portsender
#
dest port
#
sequence number
• byte stream “number” of acknowledgement number
first byte in segment’s data checksu

rwn
urg d
pointer
m
window
Acknowledgements: size
N
• seq # of next byte expected
from other side sender sequence number space
• cumulative ACK sent sent, not- usable not

ACKe yet ACKed but not usable
Q: how receiver handles out-of- d (“in-flight”) yet sent
order segments outgoing segment from

source portreceiver
• A: TCP spec doesn’t say, - up #
dest port
#
sequence number
to implementor acknowledgement number

A rwn
checksu urg d
pointer
m
TCP sequence numbers, ACKs
Host A Host B
User types‘C’
Seq=42, ACK=79, data = ‘C’
host ACKs receipt of‘C’,
echoes back ‘C’
Seq=79, ACK=43, data = ‘C’
host ACKs receipt
of echoed ‘C’
Seq=43, ACK=80
simple telnet scenario

TCP round trip time, timeout
Q: how to set TCP timeout Q: how to estimate RTT?
value? ▪SampleRTT:measured time
▪longer than RTT, but RTT varies! from segment transmission until
ACK receipt
▪too short: premature timeout,
• ignore retransmissions
unnecessary retransmissions
▪SampleRTT will vary, want
▪too long: slow reaction to estimated RTT “smoother”
segment loss • average several recent
measurements, not just current
SampleRTT

EstimatedRTT = (1- α)*EstimatedRTT + α*SampleRTT
▪ 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
(milliseconds)
RTT
sampleRT
T
EstimatedR
TT
time
(seconds)
▪timeout interval: EstimatedRTT plus “safety margin”
• large variation in EstimatedRTT: want a larger safety margin
TimeoutInterval = EstimatedRTT + 4*DevRTT
estimated “safety
RTT margin”
▪DevRTT: EWMA of SampleRTT deviation from EstimatedRTT:
DevRTT = (1-β)*DevRTT + β*|SampleRTT-EstimatedRTT|
(typically, β = 0.25)
TCP Sender (simplified)
event: data received from event: timeout
application ▪retransmit segment that
▪create segment with seq # caused timeout
▪restart timer
▪seq # is byte-stream number
of first data byte in segment
event: ACK received
▪start timer if not already
running ▪if ACK acknowledges
• think of timer as for oldest
previously unACKed segments
unACKed segment • update what is known to be
ACKed
• expiration interval:
TimeOutInterval • start timer if there are still
unACKed segments
TCP Receiver: ACK generation [RFC 5681]
Event at receiver TCP receiver action
arrival of in-order segment with delayed 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,

higher-than-expect seq. # . indicating seq. # of next expected byte
Gap detected
arrival of segment that immediate send ACK, provided that

partially or completely fills gap segment starts at lower end of gap

TCP: retransmission scenarios
Host Host Host Host
A B A B
SendBase=
Seq=92, 8 bytes of 92 Seq=92, 8 bytes of
data data
Seq=100, 20 bytes of
time
time
out
out
ACK=100 data
X
ACK=100
ACK=120
Seq=92, 8 bytes of Seq=92, 8

data SendBase=1 bytes of send cumulative
00 data
SendBase=1 ACK for 120
ACK=100 20 ACK=120
SendBase=1
20
lost ACK premature
scenario timeout
TCP: retransmission scenarios
Host Host
A B
Seq=92, 8 bytes of
data
Seq=100, 20 bytes of
data
ACK=100
X
ACK=120
Seq=120, 15 bytes of data
cumulative ACK
covers for earlier
lost ACK
TCP fast retransmit
Host A Host B
TCP fast
retransmit
if sender receives 3 additional
ACKs for same data (“triple Se q= 9
2, 8 by
Seq= data tes of
duplicate ACKs”), resend unACKed 100, 2
data
0 b yt e
s of
segment with smallest seq # X
▪ likely that unACKed segment lost,
=100
so don’t wait for timeout ACK
timeout
=100
ACK
CK =100
A
= 10 0
Receipt of three duplicate ACKs ACK
indicates 3 segments received Seq=100, 20 bytes of data
after a missing segment – lost

segment is likely. So retransmit!

Chapter 3: roadmap
• segment structure
• reliable data transfer
• flow control
• connection management
TCP flow control
applicati
on
Q: What happens if network Application removing process
layer delivers data faster than data from TCP socket
buffers
application layer removes TCP socket
data from socket buffers? receiver
buffers
TCP
cod
Network layer e
delivering IP datagram
payload into TCP
IP
socket buffers cod
e
from
sender
receiver protocol
stack
TCP flow control
applicati
on
buffers
buffers
TCP
cod
Network layer e
delivering IP datagram
payload into TCP
IP
socket buffers cod
e
from
sender
receiver protocol
stack
TCP flow control
applicati
on
buffers
buffers
TCP
cod
e
receive window
flow control: # bytes
receiver willing to accept IP
cod
e
from
sender
receiver protocol
stack
TCP flow control
applicati
on
buffers
buffers
TCP
flow control cod
e
receiver controls sender, so
sender won’t overflow IP
cod
receiver’s buffer by e
transmitting too much, too fast
from
sender
receiver protocol
stack
TCP flow control
▪TCP receiver “advertises” free buffer
space in rwnd field in TCP header to application process
• RcvBuffer size set via socket
options (typical default is 4096 bytes) RcvBuffer buffered
data
• many operating systems autoadjust
RcvBuffer
rwnd free buffer
space
▪sender limits amount of unACKed
(“in-flight”) data to received rwnd TCP segment payloads
▪guarantees receive buffer will not TCP receiver-side buffering

overflow

TCP flow control
flow control: # bytes receiver willing to accept
▪TCP receiver “advertises” free buffer

space in rwnd field in TCP header
• RcvBuffer size set via socket
receive window
options (typical default is 4096 bytes)
• many operating systems autoadjust
RcvBuffer
▪sender limits amount of unACKed
(“in-flight”) data to received rwnd
▪guarantees receive buffer will not
overflow
TCP segment format

TCP connection management
before exchanging data, sender/receiver “handshake”:
▪ agree to establish connection (each knowing the other willing to establish connection)
▪ agree on connection parameters (e.g., starting seq #s)
applicati applicati
on on
connection state: connection state:
ESTAB ESTAB
connection variables: connection Variables:
seq # client-to- seq # client-to-
server server
server-to-client server-to-client
rcvBuffer size rcvBuffer size
atnetwor
server,client networ
at server,client
k k
Socket clientSocket = Socket connectionSocket =

newSocket("hostname","port number"); welcomeSocket.accept();
Agreeing to establish a connection
2-way handshake:
Q: will 2-way handshake always

Let’s talk work in network?
ESTAB
OK ▪ variable delays
ESTAB
▪ retransmitted messages (e.g.
req_conn(x)) due to message loss
▪ message reordering
choose x
req_conn(x) ▪ can’t “see” other side
ESTAB
acc_conn(x)
ESTAB

2-way handshake scenarios
choose
x req_conn(
x) ESTA
acc_conn( B
x)
ESTA
data(x+ accept
B
1) data(x+1
ACK(x+
)
1)
connectio
n
x
completes
No problem!

choose
x req_conn(
x) ESTA
retransmit acc_conn( B
req_conn(
x) x)
ESTA
B req_conn(
x)
connectio
client n server
terminat x forgets x
es completes
ESTA
acc_conn( B
Problem:x)halfopen
connection! (no client)
choose
x req_conn(
x) ESTA
retransmit acc_conn( B
req_conn( x)
x)
ESTA
B data(x+ accept
1) data(x+1
retransmit )
data(x+1)
connectio
n server
client x
terminat forgets x
completes
es req_conn(
x)
ESTA
data(x+ B
accept
1) data(x+1
)
Problem: dup data
accepted!
TCP 3-way handshake
Server state
serverSocket = socket(AF_INET,SOCK_STREAM)
Client state serverSocket.bind((‘’,serverPort))
serverSocket.listen(1)
clientSocket = socket(AF_INET, SOCK_STREAM) connectionSocket, addr = serverSocket.accept()
LISTE
N
clientSocket.connect((serverName,serverPort)) LISTE
choose init seq N
num, x
SYNSEN send TCP SYN msg SYNbit=1,
T Seq=x choose init seq
num, y
send TCP SYNACK SYN
SYNbit=1, Seq=y msg, acking SYN RCVD
ACKbit=1;
received SYNACK(x) ACKnum=x+1
ESTA indicates server is live;
send ACK for SYNACK;
B this segment may ACKbit=1,
contain
client-to-server data ACKnum=y+1 received ACK(y)
indicates client is
live ESTA
B
A human 3-way handshake protocol
1. On belay?
2. Belay on.
3. Climbing.

Closing a TCP 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

Chapter 3: roadmap
functionality
Principles of congestion control
Congestion:
▪informally: “too many sources sending too much data too fast for
network to handle”
▪manifestations:
• long delays (queueing in router buffers)
• packet loss (buffer overflow at routers)
▪different from flow control! congestion control:
▪a top-10 problem! too many senders,
sending too fast
flow control: one sender

too fast for one receiver
Causes/costs of congestion: scenario 1
original data: λin throughput: λout
Simplest scenario:
Host A
▪ one router, infinite buffers
▪ input, output link capacity: R infinite shared
output link buffers
▪ two flows
R R
▪ no retransmissions needed
Host B
R/
Q: What happens as 2
λout
delay
arrival rate λin
throughput:
approaches R/2?
λin R/ λin R/
2 2
maximum per-connection large delays as arrival rate
throughput: R/2 λin approaches capacity
▪one router, finite buffers
▪sender retransmits lost, timed-out packet
• application-layer input = application-layer output: λin = λout
• transport-layer input includes retransmissions : λ’in λin
Host A λin : original data

λ'in: original data, plus λout
retransmitted data
R R
Host B finite shared output

link buffers
Idealization: perfect knowledge R/2
▪ sender sends only when router buffers available
throughput: λout
Host A λin : original data λin
copy λ'in: original data, plus λout R/2
retransmitted data
free buffer space!
R R

link buffers
Idealization: some perfect knowledge
▪ packets can be lost (dropped at router) due to
full buffers
▪ sender knows when packet has been dropped:
only resends if packet known to be lost

copy λ'in: original data, plus
retransmitted data
no buffer space!
R R

link buffers
Idealization: some perfect knowledge R/2
“wasted” capacity due
▪ packets can be lost (dropped at router) due to to retransmissions
throughput: λout
full buffers
when sending at
▪ sender knows when packet has been dropped: R/2, some packets
only resends if packet known to be lost are needed
retransmissions
Host A λin : original data λin R/2

λ'in: original data, plus
retransmitted data
free buffer space!
R R

link buffers
Realistic scenario: un-needed duplicates R/2
▪ packets can be lost, dropped at router due to “wasted” capacity due
throughput: λout
full buffers – requiring retransmissions to un-needed
retransmissions
▪ but sender times can time out prematurely,
sending two copies, both of which are delivered when sending at
R/2, some packets
are retransmissions,
including needed
and un-needed
Host A λin : original data λin duplicates, that are
copy R/2
timeo
ut λ'in: original data, plus delivered!
retransmitted data
free buffer space!
R R

link buffers
Realistic scenario: un-needed duplicates R/2
▪ packets can be lost, dropped at router due to “wasted” capacity due
throughput: λout
full buffers – requiring retransmissions to un-needed
retransmissions
▪ but sender times can time out prematurely,
sending two copies, both of which are delivered when sending at
R/2, some packets
are retransmissions,
including needed
and un-needed
λin R/2 duplicates, that are
delivered!
“costs” of congestion:
▪ more work (retransmission) for given receiver throughput
▪ unneeded retransmissions: link carries multiple copies of a packet
• decreasing maximum achievable throughput

▪ four senders Q: what happens as λin and λin’ increase ?
▪ multi-hop paths A: as red λin’ increases, all arriving blue pkts at upper
▪ timeout/retransmit queue are dropped, blue throughput → 0
Host B
λ'in: original data, plus
retransmitted data
finite shared
output link buffers
Host D
λout
Host C

R/
2λout
λin’ R/
2
another “cost” of congestion:

▪ when packet dropped, any upstream transmission capacity and
buffering used for that packet was wasted!

Causes/costs of congestion: insights
▪ throughput can never exceed capacity
▪ delay increases as capacity approached
▪ loss/retransmission decreases effective

throughput
▪ un-needed duplicates further decreases

effective throughput
▪ upstream transmission capacity / buffering
wasted for packets lost downstream
Approaches towards congestion control
End-end congestion control:

▪ no explicit feedback from
network
▪ congestion inferred from ACKs
data data
ACKs
observed loss, delay
▪ approach taken by TCP

Approaches towards congestion control
Network-assisted congestion
control: explicit congestion info
▪ routers provide direct feedback
to sending/receiving hosts with data data
ACKs
flows passing through congested ACKs
router
▪ may indicate congestion level or
explicitly set sending rate
▪ TCP ECN, ATM, DECbit protocols
Chapter 3: roadmap
functionality
TCP congestion control: AIMD
▪ approach: senders can increase sending rate until packet loss
(congestion) occurs, then decrease sending rate on loss event
Additive Increase Multiplicative Decrease
increase sending rate by 1 cut sending rate in half at
maximum segment size every each loss event
RTT until loss detected
TCP sender Sending rate
AIMD sawtooth
behavior: probing
for bandwidth
tim Transport Layer: 3-119

TCP AIMD: more
Multiplicative decrease detail: sending rate is
▪ Cut in half on loss detected by triple duplicate ACK (TCP Reno)
▪ Cut to 1 MSS (maximum segment size) when loss detected by
timeout (TCP Tahoe)
Why AIMD?
▪ AIMD – a distributed, asynchronous algorithm – has been
shown to:
• optimize congested flow rates network wide!
• have desirable stability properties

TCP congestion control: details
sender sequence number space
cwnd TCP sending behavior:
▪ roughly: send cwnd bytes,
wait RTT for ACKS, then
send more bytes
last byte
available but cwnd
ACKed sent, but not-
not used
TCP rate ~
~ bytes/sec
yet ACKed RT
(“in-flight”) last byte sent
T
▪ TCP sender limits transmission: LastByteSent- LastByteAcked < cwn

d
▪ cwnd is dynamically adjusted in response to observed
network congestion (implementing TCP congestion control)
TCP slow start
Host A Host B
▪when connection begins,
increase rate exponentially
until first loss event: one
RTT
segment
• initially cwnd = 1 MSS two

• double cwnd every RTT segments
• done by incrementing cwnd

for every ACK received four
segments
▪summary: initial rate is

slow, but ramps up
exponentially fast time

TCP: from slow start to congestion avoidance
Q: when should the exponential
increase switch to linear?
X
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
Summary: TCP congestion control
New
New ACK!
new ACK
duplicate ACK
dupACKcount++
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 >
dupACKcount = 0
slow Λ
ssthresh 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
timeout
New
ACK!
ssthresh = cwnd/2
cwnd = 1 New ACK
dupACKcount = 0
cwnd = ssthresh dupACKcount == 3
dupACKcount == 3 retransmit missing segment dupACKcount = 0
ssthresh= cwnd/2 ssthresh= cwnd/2
cwnd = ssthresh + 3 cwnd = ssthresh + 3
fast
recovery
duplicate ACK
cwnd = cwnd + MSS
transmit new segment(s), as allowed

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 Wmax faster, but then
approach Wmax more slowly
Wma classic TCP

x
TCP CUBIC - higher
Wmax/ throughput in this
example
2

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
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
sourc destination
e
TCP TCP
network network
link link
physical physical
packet queue almost
never empty, sometimes
overflows packet (loss)
bottleneck link (almost always busy)

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

sourc not increase end-end throughout destination
e with congested bottleneck
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
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
measured last 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 */
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

Explicit congestion notification (ECN)
TCP deployments often implement network-assisted congestion control:
▪ two bits in IP header (ToS field) marked by network router to indicate congestion
• policy to determine marking chosen by network operator
▪ congestion indication carried to destination
▪ destination sets ECE bit on ACK segment to notify sender of congestion
▪ involves both IP (IP header ECN bit marking) and TCP (TCP header C,E bit marking)
sourc TCP ACK
segment destination
e
ECE=1
TCP TCP
network network
link link
physical physical
ECN=10 ECN=11
IP
datagram Transport Layer: 3-131
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 connection 2 router
capacity R

Q: is TCP Fair?
Example: two competing TCP sessions:
▪additive increase gives slope of 1, as throughout increases
▪multiplicative decrease decreases throughput proportionally
R equal bandwidth share

Is TCP fair?
Connection 2 throughput
A: Yes, under idealized

loss: decrease window by factor of 2 assumptions:
congestion avoidance: additive increase ▪ same RTT
loss: decrease window by factor of 2
congestion avoidance: additive increase
▪ fixed number of sessions
only in congestion
avoidance
Connection 1 throughput R
Fairness: must all network apps be “fair”?
Fairness and UDP Fairness, parallel TCP
▪multimedia apps often do not connections
use TCP ▪application can open multiple
• do not want rate throttled by parallel connections between two
congestion control hosts
▪instead use UDP: ▪web browsers do this , e.g., link of
• send audio/video at constant rate, rate R with 9 existing connections:
tolerate packet loss • new app asks for 1 TCP, gets rate R/10
▪there is no “Internet police” • new app asks for 11 TCPs, gets R/2
policing use of congestion
control

Transport layer: roadmap
functionality
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
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

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
QUIC: Connection establishment
TCP
handshake QUIC
(transport handshake
layer) 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

QUIC: streams: parallelism, no HOL blocking
HTTP HTTP
GET GET HTTP
GET
HTTP HTTP
application
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.

TCP RDT TCP
error! RDT
transport
TCP Cong. Contr. TCP Cong. Contr. UDP UDP
(a) HTTP 1.1 (b) HTTP/2 with QUIC: no HOL blocking

Chapter 3: summary
▪principles behind transport Up next:
layer services: ▪leaving the network
• multiplexing, demultiplexing “edge” (application,
• reliable data transfer transport layers)
• flow control ▪into the network “core”
▪two network-layer
▪instantiation, implementation chapters:
in the Internet • data plane
• UDP • control plane
• TCP

Additional Chapter 3 slides

Go-Back-N: 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])
rdt_rcv(rcvpkt) udt_send(sndpkt[base+1])
&& corrupt(rcvpkt) …
udt_send(sndpkt[nextseqnum-
1])
rdt_rcv(rcvpkt) &&
notcorrupt(rcvpkt)
base = getacknum(rcvpkt)+1
If (base == nextseqnum)
stop_timer
else
start_timer
Go-Back-N: receiver extended FSM
any other event
udt_send(sndpkt) rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
Λ && hasseqnum(rcvpkt,expectedseqnum)
expectedseqnum=1 Wait extract(rcvpkt,data)
sndpkt = deliver_data(data)
make_pkt(expectedseqnum,ACK,chksum) sndpkt = make_pkt(expectedseqnum,ACK,chksum)
udt_send(sndpkt)
expectedseqnum++
ACK-only: always send ACK for correctly-received packet with highest

in-order seq #
• may generate duplicate ACKs
• need only remember expectedseqnum
▪out-of-order packet:
• discard (don’t buffer): no receiver buffering!
• re-ACK pkt with highest in-order seq # Transport Layer: 3-144
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)
NextSeqNum = wait start timer
InitialSeqNum for
SendBase = InitialSeqNum
event timeo
ut
retransmit not-yet-acked
segment with
smallest seq. #
ACK received, with ACK field start timer
value y
if (y > SendBase) {
SendBase = y
/* SendBase–1: last cumulatively ACKed byte */
if (there are currently not-yet-acked segments)
start timer
else stop timer
}
TCP 3-way handshake FSM
closed
Socket connectionSocket =
welcomeSocket.accept();
Λ Socket clientSocket =
newSocket("hostname","port number");
SYN(x
)
SYNACK(seq=y,ACKnum=x+1) SYN(seq=
create new socket for x)
communication back to client
listen
SYN
SYN sent
rcvd
SYNACK(seq=y,ACKnum=x
ESTAB +1)
ACK(ACKnum=y ACK(ACKnum=y
+1)
Λ +1)

Closing a TCP connection
client server
state
ESTA state
ESTA
B clientSocket.close( B
) FINbit=1,
FIN_WAIT_ can no longer
1 send but can seq=x
receive data CLOSE_WAI
ACKbit=1; T
can still
FIN_WAIT_ wait for ACKnum=x+1 send
server data
2 close
LAST_AC
FINbit=1, K
TIMED_WAI seq=y can no
longer
T send data
ACKbit=1;
timed wait ACKnum=y+1
for 2*max CLOSE
segment
lifetime
D
CLOSE
D
TCP throughput
▪avg. TCP thruput as function of window size, RTT?
• ignore slow start, assume there is always data to send
▪W: window size (measured in bytes) where loss occurs
• avg. window size (# in-flight bytes) is ¾ W
• avg. thruput is 3/4W per RTT
3 W
avg TCP thruput bytes/
4 RT sec
=
W
T
W/
2
TCP over “long, fat pipes”
▪example: 1500 byte segments, 100ms RTT, want 10 Gbps throughput
▪requires W = 83,333 in-flight segments
▪throughput in terms of segment loss probability, L [Mathis 1997]:
1.22 . MSS
TCP throughput =
RTT L
➜ to achieve 10 Gbps throughput, need a loss rate of L = 2·10-10 – a very
small loss rate!
▪versions of TCP for long, high-speed scenarios

Chapter_3_v8.0

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

Chapter_3_v8.0

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Chapter_3_v8.0

Uploaded by

Copyright:

Available Formats

Chapter 3

Transport Layer: 3-2

▪provide logical communication mobile

between application processes national or global ISP

running on different hosts

▪two transport protocols available to data link

Internet applications enterprise

▪network layer: logical household analogy:

Transport Layer: 3-7

Transport Layer: 3-8

▪TCP: Transmission Control Protocol mobile

▪services not available: data link

• delay guarantees enterprise

transport network transport

Transport Layer: 3-11

transport network transport

Transport Layer: 3-12

Transport Layer: 3-13

transport network transport

Transport Layer: 3-14

transport network transport

Transport Layer: 3-15

application P1 P2 application sock

Transport Layer: 3-16

• each datagram carries one other header

Transport Layer: 3-17

source port: source port:

source port: source port:

Transport Layer: 3-22

Transport Layer: 3-25

Transport Layer: 3-26

SNMP client SNMP server

network (IP) network

Transport Layer: 3-27

SNMP client SNMP server

(UDP) header fields values (UDP)

Transport Layer: 3-28

SNMP client SNMP server

UDP h SNMP (IP)

Transport Layer: 3-29

applicati length, in bytes of

Transport Layer: 3-30

Transport Layer: 3-31

Transport Layer: 3-34

Transport Layer: 3-37

sending receiving sending receiving

reliable service implementation

Transport Layer: 3-38

Transport Layer: 3-39

Transport Layer: 3-40

sender-side data receiver-side

udt_send() Header data Header data rdt_rcv()

Transport Layer: 3-42

▪separate FSMs for sender, receiver:

Wait for rdt_send(data) Wait for rdt_rcv(packet)

Transport Layer: 3-43

How do humans recover from “errors” during conversation?

Transport Layer: 3-44