Unit 2 NS

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
▪ Multiplexing and demultiplexing (3.2)
▪ Connectionless transport: UDP (3.3)
• UDP segment structure (3.3.1)
• UDP checksum (3.3.2)
▪ Go back N (3.4.3)
▪ Selective Repeat (3.4.4)
▪ Connection-oriented transport: TCP (3.5)
• TCP connection (3.5.1)
• TCP Segment structure (3.5.2 )
• Rotund trip time estimation and timeout (3.5.3)
• Reliable data transfer (3.5.4)
• Flow control (3.5.5)
• TCP connection management (3.5.6)
▪ TCP congestion control (3.7)
Chapter 3: roadmap
▪ Multiplexing and demultiplexing
▪ Connectionless transport: UDP
▪ Principles of reliable data transfer
(Go-back-N and Selective Repeat)
▪ Connection-oriented transport: TCP
▪ TCP congestion control

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 socket

P3 transport P4
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,
application
destination port number data
▪ host uses IP addresses & port (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

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

9157 port: ?
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: IP physical
address B
host: IP source IP,port: B,80 host: IP

address A dest IP,port: A,9157 source IP,port: C,5775 address C
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

UDP: User Datagram Protocol
Why is there a UDP?
▪ “no frills,” “bare bones”
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 UDPhtransport
UDP h SNMP msg
(UDP) header fields values (UDP)
network (IP) ▪ creates UDP segment network (IP)
link ▪ passes segment to IP 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)
message network (IP)
▪ demultiplexes message up
network
UDP h SNMP(IP)
msg
link to application via socket link
physical physical

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

data UDP segment,
(payload) including header
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
1110011001100110
1101010101010101
wraparound 11011101110111011
sum 1011101110111100
checksum 0100010001000011
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
01
1110011001100110 10
1101010101010101
wraparound 11011101110111011 Even though
numbers have
sum 1011101110111100 changed (bit
flips), no change
checksum 0100010001000011 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

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 (N=4) sende receiver
012345678 r
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 receive pkt5, discard,
ACK
(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

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 (N=4) sende receiver
012345678 r
send pkt0
012345678 send pkt1
012345678 send pkt2 receive pkt0, send ack0
012345678 send pkt3 Xloss receive pkt1, send ack1
(wait)
receive pkt3, buffer,
012345678 rcv ack0, send pkt4 send ack3
012345678 rcv ack1, send pkt5
record ack3 arrived send ack4
pkt 2 timeout send ack5
012345678 send pkt2
012345678 (but not 3,4,5)
012345678 rcv pkt2; deliver pkt2,
012345678 pkt3, pkt4, pkt5; send ack2
Q: what happens when ack2 arrives?

Selective repeat:
sender receiver
window window
(after receipt) (after receipt)
a dilemma!
012301 pkt
2 0pkt
012301 012301
2 1
pkt 2
012301
012301
2 2 2
012301
example: 012301 pkt
3 X
2
▪ seq #s: 0, 1, 2, 3 (base 4 counting)

2
012301
2 pkt will accept packet
▪ window size=3
0 with seq number 0
(a) no 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
with seq number 0
(b) oops!
Selective repeat:
sender receiver
window window
(after receipt) (after receipt)
a dilemma!
012301 pkt
2 0pkt
012301 012301
2 1
pkt 2
012301
012301
2 2 2
012301
example: 012301 pkt
3 X
2
▪ seq #s: 0, 1, 2, 3 (base 4 counting) ▪ receiver can’t

2
012301
2 pkt will accept packet
see sender0side
▪ window size=3
with seq number 0
▪ receiver
(a) no 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
with seq number 0
(b) oops!
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 sender
Sequence numbers: source port
#
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

ACKed yet ACKed but not usable
yet sent
Q: how receiver handles out-of- (“in-flight”)
order segments outgoing segment from receiver
• A: TCP spec doesn’t say, - up

source port 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
sampleRTT
EstimatedRTT
time (seconds)
▪timeout interval: EstimatedRTT plus “safety margin”
• large variation in EstimatedRTT: want a larger safety margin
TimeoutInterval = EstimatedRTT + 4*DevRTT
estimated RTT “safety 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 A Host B Host A Host B
SendBase=9
Seq=92, 8 bytes of 2 Seq=92, 8 bytes of
data data
Seq=100, 20 bytes of
timeo
timeo
ACK=100 data
ut
ut
X
ACK=100
ACK=120
Seq=92, 8 bytes of Seq=92, 8

data SendBase=10 bytes of send cumulative
0 data
SendBase=12 ACK for 120
ACK=100 0 ACK=120
SendBase=12
0
lost ACK scenario premature timeout

TCP: retransmission scenarios
Host A Host 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
Seq=92
ACKs for same data (“triple Seq=1
, 8 bytes
of data
duplicate ACKs”), resend unACKed 0 0, 20 b
ytes o
f data
segment with smallest seq # X
▪ likely that unACKed segment lost,
=100
so don’t wait for timeout ACK
=100
timeout
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
▪ Transport-layer services
• segment structure
• reliable data transfer
• flow control
• connection management
▪ Principles of congestion control
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
code
Network layer
delivering IP datagram
payload into TCP
IP
socket buffers code
from
sender
receiver protocol stack

TCP flow control
applicati
on
buffers
TCP
code
Network layer
delivering IP datagram
payload into TCP
IP
socket buffers code
from
sender

TCP flow control
applicati
on
buffers
TCP
code
receive window
flow control: # bytes
receiver willing to accept IP
code
from
sender

TCP flow control
applicati
on
buffers
TCP
flow control code
receiver controls sender, so

sender won’t overflow IP
code
receiver’s buffer by
transmitting too much, too fast
from
sender

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)
connection state: ESTAB connection state: ESTAB

connection variables: connection Variables:
seq # client-to-server seq # client-to-server
server-to-client server-to-client
rcvBuffer size rcvBuffer size
at server,client at server,client
network network
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?
▪ variable delays
ESTAB
OK
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)
ESTAB
acc_conn(x)
ESTAB
data(x+1) accept
data(x+1)
ACK(x+1)
connection
x
completes
No problem!

choose x
req_conn(x)
ESTAB
retransmit acc_conn(x)
req_conn(x)
ESTAB
req_conn(x)
connection
client x server
terminates completes forgets x
ESTAB
acc_conn(x)
Problem: half open
connection! (no client)
choose x
req_conn(x)
ESTAB
retransmit acc_conn(x)
req_conn(x)
ESTAB
data(x+1) accept
data(x+1)
retransmit
data(x+1)
connection
x server
client completes
terminates forgets x
req_conn(x)
ESTAB
data(x+1) accept
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()
LISTEN
clientSocket.connect((serverName,serverPort)) LISTEN
choose init seq num,
x
SYNSENT send TCP SYN msg SYNbit=1,
Seq=x choose init seq num,
y
send TCP SYNACK SYN RCVD
SYNbit=1, Seq=y msg, acking SYN
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
received ACK(y)
indicates client is
live ESTAB

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

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
time Transport Layer: 3-73

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- TCP rate ~
~ bytes/sec
yet ACKed not used RTT
(“in-flight”) last byte sent
▪ TCP sender limits transmission: LastByteSent- LastByteAcked < cwn

▪ cwnd is dynamically adjusted in response to observed network
d
congestion (implementing TCP congestion control)

TCP slow start
▪ when connection begins,
Host A Host B
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!
ACK! new ACK
duplicate ACK
dupACKcount++ 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
Wmax classic TCP
TCP CUBIC - higher

Wmax/2 throughput in this
example

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
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
▪ fixed number of sessions
loss: decrease window by factor of 2
congestion avoidance: additive increase
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

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”
• congestion control
▪ 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-92
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 = wait
InitialSeqNum for
SendBase = InitialSeqNum
event timeout
retransmit not-yet-acked segment
with smallest seq. #
start timer
ACK received, with ACK field 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=x)
create new socket for communication
back to client
listen
SYN
SYN sent
rcvd
SYNACK(seq=y,ACKnum=x+1)
ESTAB
ACK(ACKnum=y+1) ACK(ACKnum=y+1)
Λ

Closing a TCP connection
client state server state
ESTAB ESTAB
clientSocket.close(
) FINbit=1,
FIN_WAIT_1 can no longer
send but can seq=x
receive data CLOSE_WAIT
ACKbit=1; ACKnum=x+1
can still
FIN_WAIT_2 wait for server send
close data
LAST_ACK
FINbit=1,
TIMED_WAIT seq=y can no
longer
ACKbit=1; ACKnum=y+1 send data
timed wait
for 2*max CLOSED
segment
lifetime
CLOSED

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/sec
4 RTT
W
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

Unit 2 NS

Uploaded by

Document Information

Original Title

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

Unit 2 NS

Uploaded by

Copyright:

Available Formats

Chapter 3

Transport Layer: 3-2

Transport Layer: 3-4

transport network transport

Transport Layer: 3-5

transport network transport

Transport Layer: 3-6

Transport Layer: 3-7

transport network transport

Transport Layer: 3-8

transport network transport

Transport Layer: 3-9

application P1 P2 application socket

Transport Layer: 3-10

Transport Layer: 3-11

source port: source

source port: source

host: IP source IP,port: B,80 host: IP

Transport Layer: 3-16

Transport Layer: 3-17

Transport Layer: 3-19

Transport Layer: 3-20

SNMP client SNMP server

network (IP) network (IP)

Transport Layer: 3-21

SNMP client SNMP server

(UDP) header fields values (UDP)

network (IP) ▪ creates UDP segment network (IP)

link ▪ passes segment to IP link

Transport Layer: 3-22

SNMP client SNMP server

link to application via socket link

Transport Layer: 3-23

application length, in bytes of

Transport Layer: 3-24

Transport Layer: 3-25

Transport Layer: 3-28

Transport Layer: 3-30

first packet bit arrives

ACK arrives, send next

Transport Layer: 3-31

▪ rdt 3.0 protocol performance stinks!

Transport Layer: 3-32

Transport Layer: 3-33

first packet bit arrives

Transport Layer: 3-34

▪ cumulative ACK: ACK(n): ACKs all packets up to, including seq # n

… … Out-of-order: received but not ACKed

Transport Layer: 3-37

Transport Layer: 3-38

Transport Layer: 3-39

Transport Layer: 3-40

Q: what happens when ack2 arrives?

Transport Layer: 3-41

▪ seq #s: 0, 1, 2, 3 (base 4 counting)

▪ seq #s: 0, 1, 2, 3 (base 4 counting) ▪ receiver can’t

in scenario (b)? retransmit pkt0

Transport Layer: 3-44

▪ point-to-point: ▪ cumulative ACKs

Transport Layer: 3-45

source port dest port segment seq #: counting

Transport Layer: 3-46

first byte in segment’s data checksu