Chapter03 - UDP and TCP
Chapter03 - UDP and TCP
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
All material copyright 1996-2023
Jim Kurose, Keith Ross
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
Sender:
application ▪ is passed an application- application
app. msg
layer message
transport ▪ determines segment TThhtransport
app. msg
header fields values
network (IP) ▪ creates segment network (IP)
physical physical
Receiver:
application ▪ receives segment from IP application
▪ checks header values
transport
app. msg ▪ extracts application-layer transport
message
network (IP) network (IP)
▪ demultiplexes message up
link to application via socket link
physical physical
Th app. msg
• congestion control
• flow control
• connection setup
local or
▪ UDP: User Datagram Protocol regional ISP
application
Hnnetwork
Ht HTTP msg transport
transport
Hn Hnetwork
t HTTP msg
link network
link physical link
physical physical
Hn Ht HTTP msg
client
application application
HTTP msg
HTTP msg transport
Ht HTTP msg
de-multiplexing
application
? transport
de-multiplexing
Demultiplexing
multiplexing
application
transport
multiplexing
Multiplexing
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 fields
transport-layer segment
• 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
application application
transport transport
(UDP) (UDP)
link link
physical physical
physical physical
Transmitted: 5 6 11
Received: 4 6 11
receiver-computed sender-computed
checksum
= checksum (as received)
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: http://gaia.cs.umass.edu/kurose_ross/interactive/
Transport Layer: 3-30
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!
window size
Acknowledgements: N
SendBase=92
Seq=92, 8 bytes of data Seq=92, 8 bytes of data
timeout
ACK=100
X
ACK=100
ACK=120
SendBase=120
TCP
code
Network layer
delivering IP datagram
payload into TCP
IP
socket buffers
code
from sender
TCP
code
Network layer
delivering IP datagram
payload into TCP
IP
socket buffers
code
from sender
TCP
code
receive window
flow control: # bytes
receiver willing to accept IP
code
from sender
TCP
code
flow control
receiver controls sender, so
sender won’t overflow IP
code
receiver’s buffer by
transmitting too much, too fast
from sender
application application
network network
1. On belay?
2. Belay on.
3. Climbing.
AIMD sawtooth
behavior: probing
for bandwidth
Why AIMD?
▪ AIMD – a distributed, asynchronous algorithm – has been
shown to:
• optimize congested flow rates network wide!
• have desirable stability properties
RTT
• initially cwnd = 1 MSS
• double cwnd every RTT
• done by incrementing cwnd
for every ACK received
▪ summary: initial rate is
slow, but ramps up
exponentially fast time
Implementation:
▪ variable ssthresh
▪ on loss event, ssthresh is set to
1/2 of cwnd just before loss event
* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/
Transport Layer: 3-56
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
L transmit new segment(s), as allowed
cwnd = 1 MSS
ssthresh = 64 KB cwnd > ssthresh
dupACKcount = 0
slow L congestion
start timeout avoidance
ssthresh = cwnd/2
cwnd = 1 MSS duplicate ACK
timeout dupACKcount = 0 dupACKcount++
ssthresh = cwnd/2 retransmit missing segment
cwnd = 1 MSS
dupACKcount = 0
retransmit missing segment New
timeout
ACK!
ssthresh = cwnd/2
cwnd = 1 New ACK
dupACKcount = 0
cwnd = ssthresh dupACKcount == 3
dupACKcount == 3 retransmit missing segment dupACKcount = 0
ssthresh= cwnd/2 ssthresh= cwnd/2
cwnd = ssthresh + 3 cwnd = ssthresh + 3
retransmit missing segment retransmit missing segment
fast
recovery
duplicate ACK
cwnd = cwnd + MSS
transmit new segment(s), as allowed