CS3001-Computer-Networks-Ch3-Chapter-3.pdf

Layers
TRANSPORT LAYER
APPLICATION PRESENTATION SESSION TRANSPORT NETWORK LINK
PHYSICAL
Transport Layer: 3-2

Chapter 3: TransportLayer
TRANSPORT LAYER: SERVICES TransportLayer: 3-4
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
▪ provide logical communication
between application processes
running on different hosts
mobile network
home network
enterprise
network
national or global ISP
local or
regional ISP
datacenter
network
content
provider
network
application
transport
network
data link
physical
application
transport
network
data link
physical
▪ transport protocols actions in end
systems:
• sender: breaks application messages
into segments, passes to network layer
• receiver: reassembles segments into
messages, passes to application layer
▪ two transport protocols available to
Internet applications
• TCP, UDP
TRANSPORT LAYER: SERVICES

Transport vs. network layer services and protocols
▪network layer: logical
communicationbetween
hosts
▪transport layer: logical
communicationbetween
processes
• relies on, enhances, network
layer services
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

physical
link
network (IP)
application
physical
link
network (IP)
application
transport
Transport Layer Actions
Sender:
app. msg
▪ is passed an application-
layer message
▪ determines segment
header fields values
▪ creates segment
▪ passes segment to IP
transport
Th
Th app. msg

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

Two principal Internet transport protocols
mobile network
home network
enterprise
network
national or global ISP
local or
regional ISP
datacenter
network
content
provider
network
application
transport
network
data link
physical
application
transport
network
data link
physical
▪TCP: Transmission Control Protocol
• reliable, in-order delivery
• congestion control
• flow control
• connection setup
▪UDP: User Datagram Protocol
• unreliable, unordered delivery
• no-frills extension of “best-effort” IP
▪services not available:
• delay guarantees
• bandwidth guarantees

TRANSPORT LAYER:MULTIPLEXING Application Layer:2-9
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
physical
link
network transport
application
physical
link
network
transport
application
physical
link
network
HTTP server
client
HTTP msg
Transport Layer: 3-
10
TRANSPORT LAYER:MULTIPLEXING

transport
physical
link
network transport
application
physical
link
network
transport
application
physical
link
network
HTTP server
client
HTTP msg
Ht
HTTP msg
Transport Layer: 3-
11

transport
physical
link
network transport
application
physical
link
network
transport
application
physical
link
network
HTTP server
client
HTTP msg
Ht
HTTP msg
Ht
Hn
HTTP msg
Transport Layer: 3-
12

transport
physical
link
network transport
application
physical
link
network
transport
application
physical
link
network
HTTP server
client
HTTP msg
Ht
Hn
Transport Layer: 3-
13

transport
physical
link
network transport
application
physical
link
network
transport
application
physical
link
network
HTTP server
client1 client2
P-client1 P-client2
Transport Layer: 3-
14

Multiplexing/demultiplexing
Transport Layer: 3-
15
process
socket
use header info to deliver
received segments to correct
socket
demultiplexing at receiver:
transport
application
physical
link
network
P2
P1
transport
application
physical
link
network
P4
transport
application
physical
link
network
P3
handle data from multiple
sockets,add transport header
(later used for demultiplexing)
multiplexing at sender:

How demultiplexing works
Transport Layer: 3-
16
▪ host receives IP datagrams
• each datagram has source IP
address, destination IP address
• each datagram carries one
transport-layer segment
• each segment has source,
destination port number
▪ host uses IP addresses & port
numbers to direct segment to
appropriate socket
source port # dest port #
32 bits
application
data
(payload)
other header fields
TCP/UDP segment format

Connectionless demultiplexing
Transport Layer: 3-
17
Recall:
▪ when creating socket, must
specify host-local port #:
DatagramSocket mySocket1
= new DatagramSocket(12534);
when receiving host receives
UDP segment:
• checks destination port # in
segment
• directs UDP segment to
socket with that port #
▪ when creating datagram to
send into UDP socket, must
specify
• destination IP address
• destination port #
IP/UDP datagrams with same dest.
port #, but different source IP
addresses and/or source port
numbers will be directed to same
socket at receiving host

Connectionless demultiplexing: an example
Transport Layer: 3-
18
DatagramSocket
serverSocket = new
DatagramSocket
(6428);
transport
application
physical
link
network
P3
transport
application
physical
link
network
P1
transport
application
physical
link
network
P4
DatagramSocket mySocket1 =
new DatagramSocket (5775);
DatagramSocket mySocket2 =
new DatagramSocket
(9157);
source port: 9157
dest port: 6428
source port: 6428
dest port: 9157
source port: ?
dest port: ?
source port: ?
dest port: ?

Connection-oriented demultiplexing
Transport Layer: 3-
19
▪ TCP socket identified by
4-tuple:
• source IP address
• source port number
• dest IP address
• dest port number
▪ server may support many
simultaneous TCP sockets:
• each socket identified by its
own 4-tuple
• each socket associated with a
different connecting client
▪ demux: receiver uses all
four values (4-tuple) to
direct segment to
appropriate socket

Connection-oriented demultiplexing: example
Transport Layer: 3-
20
transport
application
physical
link
network
P1
transport
application
physical
link
P4
transport
application
physical
link
network
P2
host: IP
addressA
host: IP
address C
network
P6
P5
P3
source IP,port: A,9157
dest IP, port: B,80
source IP,port: B,80
dest IP,port: A,9157 source IP,port: C,5775
dest IP,port: B,80
source IP,port: C,9157
dest IP,port: B,80
server:IP
address B
Three segments, all destined to IP address: B,
dest port: 80 are demultiplexed to different sockets

Summary
Transport Layer: 3-
21
▪ Multiplexing, demultiplexing: based on segment, datagram
header field values
▪ UDP: demultiplexing using destinationport number (only)
▪ TCP: demultiplexing using 4-tuple: source and destinationIP
addresses, and port numbers
▪ Multiplexing/demultiplexing happen at all layers

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 LAYER: UDP
Application Layer: 2-
22

UDP: User Datagram Protocol
Transport Layer: 3-
23
▪ “no frills,” “bare bones”
Internet transport protocol
▪ “best effort” service, UDP
segments may be:
• lost
• delivered out-of-order to app
▪ no connection establishment
(which can add RTT delay)
▪ simple: no connection state
at sender, receiver
▪ small header size
▪ no congestion control
▪ UDP can blast away as fast as
desired!
▪ can function in the face of
congestion
Why is there a UDP?
▪ connectionless:
• no handshaking between UDP
sender, receiver
• each UDP segment handled
independently of others

UDP: User Datagram Protocol
Transport Layer: 3-
24
▪ 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]
TRANSPORT LAYER:UDP
Transport
Layer:3-25

SNMP server
SNMP client
transport
(UDP)
physical
link
network (IP)
application
UDP: Transport Layer Actions
Transport Layer: 3-
26
transport
(UDP)
physical
link
network (IP)
application

SNMP server
SNMP client
transport
(UDP)
physical
link
network (IP)
application
transport
(UDP)
physical
link
network (IP)
application
Transport Layer: 3-
27
UDP sender actions:
SNMP msg
▪ is passed an application-
layer message
▪ determines UDP segment
header fields values
▪ creates UDP segment
▪ passes segment to IP
UDPh
UDPh SNMP msg

SNMP server
SNMP client
transport
(UDP)
physical
link
network (IP)
application
transport
(UDP)
physical
link
network (IP)
application
Transport Layer: 3-
28
UDP receiver actions:
SNMP msg
▪ extracts application-layer
message
▪ checks UDP checksum
header value
▪ receives segment from IP
UDPh SNMP msg
▪ demultiplexes message up
to application via socket

UDP segment header
Transport Layer: 3-
29
32 bits
application
data
(payload)
UDP segment format
length checksum
length, in bytes of
UDP segment,
including header
data to/from
application layer

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

UDP checksum
sender:
▪ treat contents of UDP segment (including
UDP header fieldsand IP addresses) as
sequence of 16-bit integers
▪ checksum: addition (one’s complement sum)
of segment content
▪ checksum value put into UDP checksum
field
receiver:
▪ compute checksum of received
segment
▪ check if computed checksum
equals checksum field value:
• Not equal - error detected
• Equal - no error detected.But
maybe errors nonetheless? More
later ….
Transport Layer: 3-
31
Goal: detect errors (i.e., flipped bits) in transmitted segment

Internet checksum: an example
Transport Layer: 3-
32
example: add two 16-bit integers
sum
checksum
Note: when adding numbers, a carryout from the most significant bit needs to be
added to the result
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
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
wraparound
1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1

Internet checksum: weak protection!
Transport Layer: 3-
33
example: add two 16-bit integers
sum
checksum
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
1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
wraparound
1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
0 1
1 0
Even though
numbers have
changed (bit
flips), no change
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 additionalfunctionality on top of UDP in applicationlayer
(e.g., HTTP/3)
Transport Layer: 3-
34

TRANSPORT LAYER:RDT ApplicationLayer:2-35
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

Principles of reliable data transfer
Transport Layer: 3-
36
sending
process
data
receiving
process
data
reliablechannel
application
transport
reliable service abstraction
TRANSPORT LAYER:RDT

Transport Layer: 3-
37
sending
process
data
receiving
process
data
application
transport
reliable service implementation
unreliablechannel
network
transport
sender-side of
reliabledata
transfer protocol
receiver-side
of reliable data
transfer protocol
sending
process
data
receiving
process
data
reliablechannel
application
transport
reliable service abstraction
TRANSPORT LAYER:RDT

Transport Layer: 3-
38
sending
process
data
receiving
process
data
application
transport
unreliablechannel
network
transport
sender-side of
reliabledata
transfer protocol
receiver-side
of reliable data
transfer protocol
Complexity of reliable data
transfer protocol will depend
(strongly) on characteristics of
unreliable channel (lose,
corrupt, reorder data?)
TRANSPORT LAYER:RDT

Transport Layer: 3-
39
sending
process
data
receiving
process
data
application
transport
unreliablechannel
network
transport
sender-side of
reliabledata
transfer protocol
receiver-side
of reliable data
transfer protocol
Sender, receiver do not know
the “state” of each other, e.g.,
was a message received?
▪ unless communicated via a
message
TRANSPORT LAYER:RDT

Reliable data transfer protocol (rdt): interfaces
Transport Layer: 3-
40
sending
process
data
receiving
process
data
unreliablechannel
sender-side
implementation of
rdt reliable data
transfer protocol
receiver-side
implementation of
rdt reliable data
transfer protocol
rdt_send()
udt_send() rdt_rcv()
deliver_data()
data
Header data
Header
rdt_send(): calledfrom above,
(e.g., by app.). Passed data to
deliver to receiver upper layer
udt_send(): called by rdt
to transfer packet over
unreliablechannelto receiver
rdt_rcv(): called when packet
arrives on receiver side of
channel
deliver_data(): calledby rdt
to deliver data to upper layer
Bi-directionalcommunication over
unreliablechannel
data
packet
TRANSPORT LAYER:RDT

Reliable data transfer: getting started
Transport Layer: 3-
41
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!
state
1
state
2
event causing state transition
actions taken on state transition
state: when in this “state”
next state uniquely
determined by next
event
event
actions
▪ use finite state machines (FSM) to specify sender, receiver
TRANSPORT LAYER:RDT

rdt1.0: reliable transfer over a reliable channel
Transport Layer: 3-
42
▪ underlying channel perfectly reliable
• no bit errors
• no loss of packets
packet = make_pkt(data)
udt_send(packet)
rdt_send(data)
extract (packet,data)
deliver_data(data)
rdt_rcv(packet)
Wait for
call from
below
receiver
▪ separate FSMs for sender, receiver:
• sender sends data into underlying channel
• receiver reads data from underlying channel
sender
Wait for
call from
above
TRANSPORT LAYER:RDT

rdt2.0: channel with bit errors
Transport Layer: 3-
43
▪ 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?
TRANSPORT LAYER:RDT

rdt2.0: channel with bit errors
Transport Layer: 3-
44
▪ 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
• negativeacknowledgements(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
TRANSPORT LAYER:RDT

rdt2.0: FSM specifications
Transport Layer: 3-
45
Wait for
call from
above
udt_send(sndpkt)
Wait for
ACK or
NAK
udt_send(NAK)
rdt_rcv(rcvpkt) && corrupt(rcvpkt)
Wait for
call from
below
extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
snkpkt = make_pkt(data, checksum)
udt_send(sndpkt)
rdt_send(data)
rdt_rcv(rcvpkt) && isACK(rcvpkt)

sender
receiver
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
TRANSPORT LAYER:RDT

rdt2.0: FSM specification
Transport Layer: 3-
46
Wait for
call from
above
udt_send(sndpkt)
Wait for
ACK or
NAK
udt_send(NAK)
Wait for
call from
below
deliver_data(data)
udt_send(ACK)
udt_send(sndpkt)
rdt_send(data)

sender
receiver
Note: “state” of receiver (did the receiver get my
message correctly?) isn’t known to sender unless
somehow communicatedfrom receiver to sender
▪ that’s why we need a protocol!
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
isNAK(rcvpkt)
isACK(rcvpkt)
TRANSPORT LAYER:RDT

rdt2.0: operation with no errors
Transport Layer: 3-
47
Wait for
call from
above
udt_send(sndpkt)
udt_send(sndpkt)
udt_send(NAK)
Wait for
ACK or
NAK
Wait for
call from
below
rdt_send(data)

deliver_data(data)
udt_send(ACK)
sender
receiver
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
TRANSPORT LAYER:RDT

rdt2.0: corrupted packet scenario
Transport Layer: 3-
48
Wait for
call from
above
udt_send(sndpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
isNAK(rcvpkt)
Wait for
ACK or
NAK
Wait for
call from
below
rdt_send(data)
udt_send(NAK)
deliver_data(data)
udt_send(ACK)

sender
receiver
TRANSPORT LAYER:RDT

rdt2.0 has a fatal flaw!
Transport Layer: 3-
49
what happens if ACK/NAK
corrupted?
▪ sender doesn’t know what
happened at receiver!
▪ can’t just retransmit: possible
duplicate
handlingduplicates:
▪ sender retransmits current pkt
if ACK/NAK corrupted
▪ sender adds sequence number
to each pkt
▪ receiver discards (doesn’t
deliver up) duplicate pkt
stop and wait
sender sends one packet, then
waits for receiver response
TRANSPORT LAYER:RDT

rdt2.1: sender, handling garbled ACK/NAKs
Transport Layer: 3-
50
Wait for
call 0 from
above
Wait for
ACK or
NAK 0
sndpkt = make_pkt(0, data, checksum)
udt_send(sndpkt)
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) ||
isNAK(rcvpkt) )
udt_send(sndpkt)
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& (corrupt(rcvpkt) ||
isNAK(rcvpkt) )
Wait for
call 1 from
above
Wait for
ACK or
NAK 1
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& isACK(rcvpkt)

rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) &&
isACK(rcvpkt)

TRANSPORT LAYER:RDT

rdt2.1: receiver, handling garbled ACK/NAKs
Transport Layer: 3-
51
Wait for
0 from
below
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK,chksum)
udt_send(sndpkt)
Wait for
1 from
below
&& has_seq0(rcvpkt)
deliver_data(data)
udt_send(sndpkt)
sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) &&
has_seq0(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) &&
has_seq1(rcvpkt)
udt_send(sndpkt)
rdt_rcv(rcvpkt) && (corrupt(rcvpkt)
sndpkt = make_pkt(NAK, chksum)
udt_send(sndpkt)
TRANSPORT LAYER:RDT

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

rdt2.2: a NAK-free protocol
Transport Layer: 3-
53
As we will see, TCP uses this approach to be NAK-free
TRANSPORT LAYER:RDT
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:
retransmitcurrentpkt

rdt2.2: sender, receiver fragments
Transport Layer: 3-
54
Wait for
call 0 from
above
udt_send(sndpkt)
rdt_send(data)
udt_send(sndpkt)
rdt_rcv(rcvpkt) &&
( corrupt(rcvpkt) ||
isACK(rcvpkt,1) )
rdt_rcv(rcvpkt)
&& isACK(rcvpkt,0)
Wait for
ACK
0
sender FSM
fragment
&& has_seq1(rcvpkt)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt)
Wait for
0 from
below
rdt_rcv(rcvpkt) &&
(corrupt(rcvpkt) ||
has_seq1(rcvpkt))
udt_send(sndpkt)
receiver FSM
fragment

TRANSPORT LAYER:RDT

rdt3.0: channels with errors and loss
Transport Layer: 3-
55
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?
TRANSPORT LAYER:RDT

rdt3.0: channels with errors and loss
Transport Layer: 3-
56
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
timeout
▪ use countdowntimer to interrupt after “reasonable” amount
of time
TRANSPORT LAYER:RDT

rdt3.0 sender
Transport Layer: 3-
57
Wait
for
ACK0
sndpkt = make_pkt(0,data, checksum)
udt_send(sndpkt)
start_timer
rdt_send(data)
Wait for
call 1 from
above
udt_send(sndpkt)
start_timer
rdt_send(data)
rdt_rcv(rcvpkt)
&& isACK(rcvpkt,0)
stop_timer
rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1)
stop_timer
Wait for
call 0 from
above
Wait
for
ACK1
TRANSPORT LAYER:RDT

rdt3.0 sender
Transport Layer: 3-
58
Wait
for
ACK0
udt_send(sndpkt)
start_timer
rdt_send(data)
Wait for
call 1 from
above
udt_send(sndpkt)
start_timer
rdt_send(data)
rdt_rcv(rcvpkt)
&& isACK(rcvpkt,0)
stop_timer
rdt_rcv(rcvpkt)
&& isACK(rcvpkt,1)
stop_timer
udt_send(sndpkt)
start_timer
timeout
Wait for
call 0 from
above
Wait
for
ACK1

rdt_rcv(rcvpkt)
rdt_rcv(rcvpkt) &&
isACK(rcvpkt,1))

rdt_rcv(rcvpkt)

udt_send(sndpkt)
start_timer
timeout
rdt_rcv(rcvpkt) &&
isACK(rcvpkt,0))

TRANSPORT LAYER:RDT

rdt3.0 in action
Transport Layer: 3-
59
sender receiver
rcv pkt1
rcv pkt0
send ack0
send ack1
send ack0
rcv ack0
send pkt0
send pkt1
rcv ack1
send pkt0
rcv pkt0
pkt0
pkt0
pkt1
ack1
ack0
ack0
(a) no loss
sender receiver
rcv pkt1
rcv pkt0
send ack0
send ack1
send ack0
rcv ack0
send pkt0
send pkt1
rcv ack1
send pkt0
rcv pkt0
pkt0
pkt0
ack1
ack0
ack0
(b) packet loss
pkt1
X
loss
pkt1
timeout
resend pkt1
TRANSPORT LAYER:RDT

rdt3.0 in action
Transport Layer: 3-
60
rcv pkt1
send ack1
(detect duplicate)
pkt1
sender receiver
rcv pkt1
rcv pkt0
send ack0
send ack1
send ack0
rcv ack0
send pkt0
send pkt1
rcv ack1
send pkt0
rcv pkt0
pkt0
pkt0
ack1
ack0
ack0
(c) ACK loss
ack1
X
loss
pkt1
timeout
resend pkt1
rcv pkt1
send ack1
(detect duplicate)
pkt1
sender receiver
rcv pkt1
send ack0
rcv ack0
send pkt1
send pkt0
rcv pkt0
pkt0
ack0
(d) premature timeout/ delayed ACK
pkt1
timeout
resend pkt1
ack1
ack1
send ack1
send pkt0
rcv ack1
pkt0
rcv pkt0
send ack0
ack0
pkt1
(ignore)
rcv ack1
TRANSPORT LAYER:RDT

Performance of rdt3.0 (stop-and-wait)
Transport Layer: 3-
61
▪ example: 1 Gbps link, 15 ms prop. delay, 8000 bit packet
▪U sender: utilization – fraction of time sender busy sending
Dtrans =
L
R
8000 bits
109 bits/sec
= = 8 microsecs
• time to transmit packet into channel:
TRANSPORT LAYER:RDT

rdt3.0: stop-and-wait operation
Transport Layer: 3-
62
first packet bit transmitted, t = 0
sender receiver
RTT
first packet bit arrives
last packet bit arrives, send ACK
ACK arrives, send next
packet, t = RTT + L / R
TRANSPORT LAYER:RDT

rdt3.0: stop-and-wait operation
Transport Layer: 3-
63
sender receiver
Usender
=
L / R
RTT
RTT
L/R
+ L / R
= 0.00027
=
.008
30.008
▪ rdt 3.0 protocol performance stinks!
▪ Protocol limits performance of underlying infrastructure (channel)
TRANSPORT LAYER:RDT

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

Pipelining: increased utilization
Transport Layer: 3-
65
first packet bit transmitted, t = 0
sender receiver
RTT
last bit transmitted, t = L / R
first packet bit arrives
last packet bit arrives, send ACK
ACK arrives, send next
packet, t = RTT + L / R
last bit of 2nd packet arrives, send ACK
last bit of 3rd packet arrives, send ACK
3-packet pipelining increases
utilization by a factor of 3
U
sender =
.0024
30.008
= 0.00081
3L / R
RTT + L / R
=
TRANSPORT LAYER:RDT

Go-Back-N: sender
Transport Layer: 3-
66
▪ 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
TRANSPORT LAYER:RDT

Go-Back-N: receiver
Transport Layer: 3-
67
rcv_base
received and ACKed
Out-of-order: received but not ACKed
Not received
Receiver view of sequence number space:
… …
TRANSPORT LAYER:RDT
• may generate duplicate ACKs
• need only remember rcv_base
ACK-only: always send ACK for
correctly-received packet so
far, with highest in-order seq #
• can discard (don’t buffer) or buffer: an implementation
decision
• re-ACK pkt with highest in-order seq #
on receipt of out-of-order
packet:

Go-Back-N in action
Transport Layer: 3-
68
send pkt0
send pkt1
send pkt2
send pkt3
(wait)
sender receiver
receive pkt0, send ack0
receive pkt3, discard,
(re)send ack1
send pkt2
send pkt3
send pkt4
send pkt5
Xloss
pkt 2 timeout
(re)send ack1
(re)send ack1
rcv pkt2, deliver, send ack2
ignore duplicate ACK
sender window (N=4)
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8
rcv ack0, send pkt4
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8 rcv ack1, send pkt5
TRANSPORT LAYER:RDT

Selective repeat
Transport Layer: 3-
69
▪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
TRANSPORT LAYER:RDT

Selective repeat: sender, receiver windows
Transport Layer: 3-
70
TRANSPORT LAYER:RDT

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

Selective Repeat in action
Transport Layer: 3-
72
send pkt0
send pkt1
send pkt2
send pkt3
(wait)
sender receiver
send pkt2
(but not 3,4,5)
Xloss
pkt 2 timeout
sender window (N=4)
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8
rcv ack0, send pkt4
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8
0 1 2 3 4 5 6 7 8 rcv ack1, send pkt5
receive pkt3, buffer,
send ack3
record ack3 arrived
send ack4
send ack5
rcv pkt2; deliver pkt2,
pkt3, pkt4, pkt5; send ack2
Q: what happens when ack2 arrives?
TRANSPORT LAYER:RDT

Selective repeat:
a dilemma!
Transport Layer: 3-
73
0 1 2 3 0 1 2
0 1 2 3 0 1 2
0 1 2 3 0 1 2
pkt0
pkt1
pkt2
0 1 2 3 0 1 2 pkt0
timeout
retransmit pkt0
0 1 2 3 0 1 2
0 1 2 3 0 1 2
0 1 2 3 0 1 2
X
X
X
will accept packet
with seq number 0
(b) oops!
receiver window
(after receipt)
sender window
(after receipt)
0 1 2 3 0 1 2
0 1 2 3 0 1 2
0 1 2 3 0 1 2
pkt0
pkt1
pkt2
0 1 2 3 0 1 2
pkt0
0 1 2 3 0 1 2
0 1 2 3 0 1 2
0 1 2 3 0 1 2
X
will accept packet
with seq number 0
0 1 2 3 0 1 2 pkt3
(a) no problem
example:
▪ seq #s: 0, 1, 2, 3 (base 4 counting)
▪ window size=3
TRANSPORT LAYER:RDT

Selective repeat:
a dilemma!
Transport Layer: 3-
74
Q: what relationship is needed
between sequence # size and
window size to avoid problem
in scenario (b)?
0 1 2 3 0 1 2
0 1 2 3 0 1 2
0 1 2 3 0 1 2
pkt0
pkt1
pkt2
0 1 2 3 0 1 2 pkt0
timeout
retransmit pkt0
0 1 2 3 0 1 2
0 1 2 3 0 1 2
0 1 2 3 0 1 2
X
X
X
will accept packet
with seq number 0
(b) oops!
receiver window
(after receipt)
sender window
(after receipt)
0 1 2 3 0 1 2
0 1 2 3 0 1 2
0 1 2 3 0 1 2
pkt0
pkt1
pkt2
0 1 2 3 0 1 2
pkt0
0 1 2 3 0 1 2
0 1 2 3 0 1 2
0 1 2 3 0 1 2
X
will accept packet
with seq number 0
0 1 2 3 0 1 2 pkt3
(a) no problem
example:
▪ seq #s: 0, 1, 2, 3 (base 4 counting)
▪ window size=3
▪ receiver can’t
see senderside
▪ receiver
behavior
identical in both
cases!
▪ something’s
(very) wrong!
TRANSPORT LAYER:RDT

TCP: overview RFCs: 793,1122, 2018, 5681, 7323
Transport Layer: 3-
75
▪ cumulative ACKs
▪ pipelining:
• TCP congestion and flow control
set window size
▪ connection-oriented:
• handshaking (exchange of control
messages) initializes sender,
receiver state before data exchange
▪ flow controlled:
• sender will not overwhelm receiver
▪ point-to-point:
• one sender, one receiver
▪ reliable, in-order byte
steam:
• no “message boundaries"
▪ full duplex data:
• bi-directional data flow in
same connection
• MSS: maximum segment size
TRANSPORT LAYER:TCP

TCP segment structure
Transport Layer: 3-
76
32 bits
not
used receive window flow control: # bytes
receiver willing to accept
sequence number
segment seq #: counting
bytes of data into bytestream
(not segments!)
application
data
(variable length)
data sent by
application into
TCP socket
A
acknowledgement number
ACK: seq # of next expected
byte; A bit: this is an ACK
options (variable length)
TCP options
head
len
length (of TCP header)
checksum
Internet checksum
RST, SYN, FIN: connection
management
F
S
R
Urg data pointer
P
U
C E
C, E: congestion notification
TRANSPORT LAYER:TCP

TCP sequence numbers, ACKs
Transport Layer: 3-
77
Sequence numbers:
• byte stream “number” of
first byte in segment’s data
sequence number
checksum
rwnd
urg pointer
outgoing segment from receiver
A
sent
ACKed
sent, not-
yet ACKed
(“in-flight”)
usable
but not
yet sent
not
usable
window size
N
sender sequence number space
sequence number
checksum
rwnd
urg pointer
outgoing segment from sender
Acknowledgements:
• seq # of next byte expected
from other side
• cumulative ACK
Q: how receiver handles out-of-
order segments
• A: TCP spec doesn’t say, - up
to implementor
TRANSPORT LAYER:TCP

TCP sequence numbers, ACKs
Transport Layer: 3-
78
host ACKs receipt
of echoed ‘C’
host ACKs receipt
of‘C’, echoes back ‘C’
simple telnet scenario
Host B
Host A
User types‘C’
Seq=42, ACK=79, data = ‘C’
Seq=79, ACK=43, data = ‘C’
Seq=43, ACK=80
TRANSPORT LAYER:TCP

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

Transport Layer: 3-
80
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
100
150
200
250
300
350
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
RTT
(milliseconds)
SampleRTT Estimated RTT
RTT
(milliseconds)
RTT:gaia.cs.umass.eduto fantasia.eurecom.fr
sampleRTT
EstimatedRTT
time (seconds)
TRANSPORT LAYER:TCP

Transport Layer: 3-
81
▪ timeout interval: EstimatedRTT plus “safety margin”
• large variation in EstimatedRTT: want a larger safety margin
TimeoutInterval = EstimatedRTT + 4*DevRTT
estimated RTT “safety margin”
* Check out the online interactive exercises formore examples:http://gaia.cs.umass.edu/kurose_ross/interactive/
DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|
(typically,  = 0.25)
▪ DevRTT: EWMA of SampleRTT deviation from EstimatedRTT:
TRANSPORT LAYER:TCP

TCP Sender (simplified)
Transport Layer: 3-
82
event: data received from
application
▪ create segment with seq #
▪ seq # is byte-stream number
of first data byte in segment
▪ start timer if not already
running
• think of timer as for oldest
unACKed segment
• expiration interval:
TimeOutInterval
event: timeout
▪ retransmit segment that
caused timeout
▪ restart timer
event: ACK received
▪ if ACK acknowledges
previously unACKed segments
• update what is known to be
ACKed
• start timer if there are still
unACKed segments
TRANSPORT LAYER:TCP

TCP Receiver: ACK generation [RFC 5681]
Transport Layer: 3-
83
Event at receiver
arrival of in-order segment with
expected seq #. All data up to
expected seq # already ACKed
arrival of in-order segment with
expected seq #. One other
segment has ACK pending
arrival of out-of-order segment
higher-than-expect seq. # .
Gap detected
arrival of segment that
partially or completely fills gap
TCP receiver action
delayed ACK. Wait up to 500ms
for next segment. If no next segment,
send ACK
immediately send single cumulative
ACK, ACKing both in-order segments
immediately send duplicateACK,
indicating seq. # of next expected byte
immediate send ACK, provided that
segment starts at lower end of gap
TRANSPORT LAYER:TCP

TCP: retransmission scenarios
Transport Layer: 3-
84
lost ACK scenario
Host B
Host A
Seq=92, 8 bytes of data
ACK=100
X
ACK=100
timeout
premature timeout
Host B
Host A
Seq=92, 8
bytes of data
ACK=120
timeout
ACK=100
ACK=120
SendBase=100
SendBase=120
SendBase=120
SendBase=92
send cumulative
ACK for 120
TRANSPORT LAYER:TCP

TCP: retransmission scenarios
Transport Layer: 3-
85
cumulative ACK covers
for earlier lost ACK
Host B
Host A
X
ACK=100
ACK=120
TRANSPORT LAYER:TCP

TCP fast retransmit
Transport Layer: 3-
86
Host B
Host A
timeout
X
Receipt of three duplicate ACKs
indicates 3 segments received
after a missing segment – lost
segment is likely. So retransmit!
if sender receives 3 additional
ACKs for same data (“triple
duplicate ACKs”), resend unACKed
segment with smallest seq #
▪ likely that unACKed segment lost,
so don’t wait for timeout
TCP fast retransmit
TRANSPORT LAYER:TCP

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 LAYER:TCP
87

TCP connection management
Transport Layer: 3-
88
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 variables:
seq # client-to-server
server-to-client
rcvBuffer size
at server,client
application
network
connection state: ESTAB
connection Variables:
seq # client-to-server
server-to-client
rcvBuffer size
at server,client
application
network
Socket clientSocket =
newSocket("hostname","port number");
Socket connectionSocket =
welcomeSocket.accept();
TRANSPORT LAYER:TCP

Agreeing to establish a connection
Transport Layer: 3-
89
Q: will 2-way handshake always
work in network?
▪ variable delays
▪ retransmitted messages (e.g.
req_conn(x)) due to message loss
▪ message reordering
▪ can’t “see” other side
2-way handshake:
Let’s talk
OK
ESTAB
ESTAB
choose x
req_conn(x)
ESTAB
ESTAB
acc_conn(x)
TRANSPORT LAYER:TCP

2-way handshake scenarios
Transport Layer: 3-
90
connection
x completes
choose x
req_conn(x)
ESTAB
ESTAB
acc_conn(x)
data(x+1) accept
data(x+1)
ACK(x+1)
No problem!
TRANSPORT LAYER:TCP

Transport Layer: 3-
91
ESTAB
retransmit
req_conn(x)
req_conn(x)
client
terminates
server
forgets x
connection
x completes
choose x
req_conn(x)
ESTAB
ESTAB
acc_conn(x)
acc_conn(x)
Problem: half open
connection! (no client)
TRANSPORT LAYER:TCP

client
terminates
ESTAB
choose x
req_conn(x)
ESTAB
acc_conn(x)
data(x+1) accept
data(x+1)
connection
x completes server
forgets x
Problem: dup data
accepted!
data(x+1)
retransmit
data(x+1)
accept
data(x+1)
retransmit
req_conn(x)
ESTAB
req_conn(x)
TRANSPORT LAYER:TCP
Transport Layer: 3-
92

TCP 3-way handshake
Transport Layer: 3-
93
SYNbit=1, Seq=x
choose init seq num, x
send TCP SYN msg
ESTAB
SYNbit=1, Seq=y
ACKbit=1; ACKnum=x+1
choose init seq num, y
send TCP SYNACK
msg, acking SYN
ACKbit=1, ACKnum=y+1
received SYNACK(x)
indicates server is live;
send ACK for SYNACK;
this segment may contain
client-to-server data
received ACK(y)
indicates client is live
SYNSENT
ESTAB
SYN RCVD
Client state
LISTEN
Server state
LISTEN
clientSocket = socket(AF_INET, SOCK_STREAM)
serverSocket = socket(AF_INET,SOCK_STREAM)
serverSocket.bind((‘’,serverPort))
serverSocket.listen(1)
connectionSocket, addr = serverSocket.accept()
clientSocket.connect((serverName,serverPort))
TRANSPORT LAYER:TCP

A human 3-way handshake protocol
Transport Layer: 3-
94
1. On belay?
2. Belay on.
3. Climbing.
TRANSPORT LAYER:TCP

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 LAYER:CONGESTION CONTROL
95

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!
Principles of congestion control
Transport Layer: 3-
96
congestion control:
too many senders,
sending too fast
flow control: one sender
too fast for one receiver
▪ a top-10 problem!

Causes/costs of congestion: scenario 1
Transport Layer: 3-
97
Simplest scenario:
maximum per-connection
throughput: R/2
Host A
Host B
throughput: out
large delaysas arrivalrate
in approaches capacity
Q: What happens as
arrival rate in
approaches R/2?
original data: in
R
▪ two flows
▪ one router, infinite buffers
▪ input, output link capacity: R infinite shared
output link buffers
R
▪ no retransmissions needed
R/2
delay
in
R/2
R/2

out
in
throughput:

Transport Layer: 3-
98
▪ one router, finite buffers
Host A
Host B
in : original data
'in:original data, plus
retransmitted data
finite shared output
link buffers
▪ sender retransmits lost, timed-out packet
• application-layer input = application-layer output: in = out
• transport-layer input includes retransmissions : ’in in
out
R
R

Host A
Host B
retransmitted data
link buffers
Transport Layer: 3-
99
copy
free buffer space!
Idealization: perfect knowledge
▪ sender sends only when router buffers available
out
R
R
R/2
in
R/2

out
throughput:

Host A
Host B
retransmitted data
link buffers
R
R
Transport Layer: 3-
100
copy
no buffer space!
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

Host A
Host B
retransmitted data
link buffers
R
R
Transport Layer: 3-
101
free buffer space!
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
when sending at
R/2, some packets
are needed
retransmissions
in
R/2

out
throughput:
R/2
“wasted” capacity due
to retransmissions

Host A
Host B
retransmitted data
link buffers
R
R
Transport Layer: 3-
102
copy
timeout
Realistic scenario: un-needed duplicates
▪ packets can be lost, dropped at router due to
full buffers – requiring retransmissions
▪ but sender times can time out prematurely,
sending two copies, both of which are delivered
free buffer space!
when sending at
R/2, some packets
are retransmissions,
including needed
and un-needed
duplicates,that are
delivered!
to un-needed
retransmissions
in
R/2

out
throughput:
R/2

Transport Layer: 3-
103
“costs” of congestion:
▪ more work (retransmission) for given receiver throughput
▪ unneeded retransmissions: link carries multiple copies of a packet
• decreasing maximum achievable throughput
Realistic scenario: un-needed duplicates
▪ packets can be lost, dropped at router due to
full buffers – requiring 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
duplicates,that are
delivered!
to un-needed
retransmissions
in
R/2

out
throughput:
R/2

Transport Layer: 3-
104
▪ four senders
▪ multi-hop paths
▪ timeout/retransmit
Q: what happens as in and in
’ increase ?
A: as red in
’ increases, all arriving blue pkts at upper
queue are dropped, blue throughput  0
finite shared
output link buffers
HostA
out
Host B
Host C
Host D
retransmitted data

Transport Layer: 3-
105
another “cost” of congestion:
▪ when packet dropped, any upstream transmission capacity and
buffering used for that packet was wasted!
R/2
R/2

out
in
’

Causes/costs of congestion: insights
Transport Layer: 3-
106
▪ upstream transmission capacity / buffering
wasted for packets lost downstream
R/2
R/2
l
out
lin
’
▪ delay increases as capacity approached
R/2
delay
lin
▪ un-needed duplicates further decreases
effective throughput
lin
R/2
l
out
throughput:
R/2
▪ loss/retransmission decreases effective
throughput
lin
R/2
l
out
throughput:
R/2
▪ throughput can never exceed capacity
R/2
lin
R/2
l
out
throughput:

Approaches towards congestion control
End-end congestioncontrol:
no explicit feedback from
network
congestion inferred from
observed loss, delay
Transport Layer: 3-
107
data
data
ACKs
ACKs
▪ approach taken by TCP

Approaches towards congestion control
TCP ECN, ATM, DECbit protocols
Transport Layer: 3-
108
data
data
ACKs
ACKs
explicit congestion info
Network-assisted congestion
control:
▪ routers provide direct feedback
to sending/receiving hosts with
flows passing through congested
router
▪ may indicate congestion level or
explicitly set sending rate

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 LAYER:TCPCONGESTION CONTROL
Transport Layer: 3-
109

TCP congestion control: AIMD
▪ approach: senders can increase sending rate until packet loss
(congestion) occurs, then decrease sending rate on loss event
AIMD sawtooth
behavior: probing
for bandwidth
TCP
sender
Sending
rate
time
increase sending rate by 1
maximum segment size every
RTT until loss detected
Additive Increase
cut sending rate in half at
each loss event
Multiplicative Decrease
Transport Layer: 3-
110

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

TCP congestion control: details
▪ TCP sender limits transmission:
▪ cwnd is dynamically adjusted in response to observed
network congestion (implementing TCP congestion control)
LastByteSent- LastByteAcked < cwnd
last byte
ACKed
last byte sent
cwnd
sender sequence number space
availablebut
not used
TCP sending behavior:
▪ roughly: send cwnd bytes,
wait RTT for ACKS, then
send more bytes
TCP rate ~
~
cwnd
RTT
bytes/sec
sent, but not-
yet ACKed
(“in-flight”)
Transport Layer: 3-
112

TCP slow start
▪ when connection begins,
increase rate exponentially
until first loss event:
• initially cwnd = 1 MSS
• double cwnd every RTT
• done by incrementing cwnd
for every ACK received
Host A Host B
RTT
time
▪ summary: initial rate is
slow, but ramps up
exponentially fast
Transport Layer: 3-
113

TCP: from slow start to congestion avoidance
Q: when should the exponential
increase switch to linear?
A: when cwnd gets to 1/2 of its
value before timeout.
Implementation:
▪ variable ssthresh
▪ on loss event, ssthresh is set to
1/2 of cwnd just before loss event
* Check out the online interactive exercises formore examples:http://gaia.cs.umass.edu/kurose_ross/interactive/
X
Transport Layer: 3-
114

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

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 LAYER:EVOLUTION
Transport Layer: 3-
116

Evolving transport-layer functionality
TCP, UDP: principal transport protocols for 40 years
different “flavors” of TCP developed, for specific scenarios:
▪ moving transport–layer functions to application layer, on top of UDP
• HTTP/3: QUIC
Scenario Challenges
Long, fat pipes (large data
transfers)
Many packets “in flight”; loss shuts down
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
TRANSPORT LAYER:EVOLUTION
Transport Layer: 3-
117

CS3001-Computer-Networks-Ch3-Chapter-3.pdf

More Related Content

Similar to CS3001-Computer-Networks-Ch3-Chapter-3.pdf (20)

More from MujtabaVlogs (19)

Recently uploaded (20)

CS3001-Computer-Networks-Ch3-Chapter-3.pdf