3.5_TCP_video_slides_discover_rdt_protocol.pptx

Transport Layer
 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
COMPSCI 453 Computer Networks
Professor Jim Kurose
College of Information and Computer Sciences
University of Massachusetts
Class textbook:
Computer Networking: A Top-
Down Approach (8th
ed.)
J.F. Kurose, K.W. Ross
Pearson, 2020
http://gaia.cs.umass.edu/kurose_ross

TCP: overview RFCs: 793,1122, 2018, 5681, 7323
 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

2. Reliable, In-Order Byte
Stream
 TCP provides:
1. Reliable delivery:
If a packet is lost or corrupted, TCP retransmits it.
2. In-order delivery:
Even if packets arrive out of order, TCP reorders them
before delivering to the application.
3. Byte stream:
TCP treats all the data as one long stream of bytes, like
this: HELLO WORLD example.
Each byte has a sequence number (used for
reliability and ordering).
So TCP is managing this long “stream of bytes,” not
separate packets.
Transport Layer: 3-3
1. Point-to-Point
TCP is point-to-point,
meaning:
One connection has exactly
one sender and one receiver.
Example:
When your browser connects
to a web server
that’s one TCP connection
between your computer and
that server.
(Unlike UDP, TCP doesn’t do
one-to-many or broadcast
communication.)
Byte
Number
1 2 3 4 5 6 7 ...
Data H E L L O W ...

 4. MSS — Maximum Segment
Size
 MSS means Maximum Segment
Size — the largest chunk of data
(in bytes) that TCP can send in
one segment.
 Typical MSS ≈ 1460 bytes (for
Ethernet, since total frame =
1500 bytes).
 Example:
If MSS = 1000 bytes → TCP
sends at most 1000 bytes of
user data per segment.
 3. Full Duplex Data
 TCP allows full duplex
communication — data
can flow in both directions
simultaneously.
 Example:
While your browser is
sending a request to a
web server, the server can
also start sending data
back at the same time.

6. Pipelining
 TCP allows multiple packets to
be sent before receiving an
ACK (unlike Stop-and-Wait).
This improves efficiency.
 The number of
unacknowledged packets that
can be in flight depends on the
window size (defined by flow
control and congestion control).
5. Cumulative
Acknowledgments (ACKs)
TCP uses cumulative ACKs,
which means:
The ACK number represents
the next byte expected by the
receiver.
Example:
If the receiver has received
bytes 1–500, it will send ACK
= 501,
meaning “I got everything up
to 500, now send me from
501.”
If packet 501–600 is lost, it
keeps sending ACK = 501 until
it gets that data.

8. Congestion Control (Network Side)
 Congestion control prevents the
network (not just the receiver) from
getting overloaded.
TCP automatically slows down when
it detects congestion.
 Main algorithms:
• Slow Start
• Congestion Avoidance
• Fast Retransmit
• Fast Recovery
 These help maintain fairness and
stability in the Internet.
7. Flow Control (Receiver Side)
 Flow control ensures the
sender doesn’t overwhelm
the receiver.
 The receiver tells the sender
how much data it can handle
— this is called the Receive
Window (rwnd).
 Example:
If rwnd = 4000 bytes → sender
can send 4000 bytes total
before waiting for an ACK.
 This prevents the receiver’s
buffer from overflowing.

10. Flow Controlled The
sender will not overwhelm the
receiver.
TCP adjusts its sending rate
based on:
•Receiver’s buffer capacity
(flow control)
•Network congestion
(congestion control)
That’s why TCP is often called
“reliable and self-adjusting.”
 9. Connection-Oriented
(Handshake)
 TCP is connection-oriented,
meaning it establishes a
connection before sending
data.
This is done using a 3-way
handshake:
1.SYN: Sender requests
connection
2.SYN-ACK: Receiver agrees
3.ACK: Sender confirms
 After this, both sides are ready
to exchange data.
This handshake initializes
sequence numbers, buffers,
and states.

TCP segment structure
source port # dest port #
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

TCP sequence numbers, ACKs
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

TCP sequence numbers, ACKs
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

TCP round trip time, timeout
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

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.edu to fantasia.eurecom.fr
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”
* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/
DevRTT = (1-)*DevRTT + *|SampleRTT-EstimatedRTT|
(typically,  = 0.25)
 DevRTT: EWMA of SampleRTT deviation from EstimatedRTT:

TCP Sender (works based on events)
event: data received from application
•The application (like a browser or email app) gives
data to TCP to send.
•TCP creates a segment (packet) to send that data.
•TCP adds a sequence number (seq#) →
This number shows the byte number of the first
byte of data in that segment.
(So, it helps the receiver keep everything in order.)
•TCP starts a timer — but only if it’s not already
running.
•The timer is for the oldest segment that has been
sent but not yet acknowledged (ACKed).
•The TimeOutInterval is the time TCP waits for an
ACK before it decides to retransmit.
event: timeout
• If the timer runs out (no ACK received
in time), TCP assumes the segment is
lost.
•It retransmits that segment — the
one that caused the timeout.
•Then it restarts the timer again.
event: ACK received
•The receiver sends an ACK to confirm it received
data.
•When the sender gets this ACK, it checks:
•Does this ACK cover (acknowledge) any data that
was still unacknowledged?
If yes those segments are now considered
→
successfully delivered.
•TCP then updates its record of which bytes have
been acknowledged.
•If there are still some unacknowledged
segments, TCP keeps the timer running (or
restarts it).
•If everything is acknowledged, it stops the timer.

TCP Receiver: ACK generation [RFC 5681]
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 duplicate ACK,
indicating seq. # of next expected byte
immediate send ACK, provided that
segment starts at lower end of gap

TCP: retransmission scenarios
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

TCP: retransmission scenarios
cumulative ACK
covers for earlier lost
ACK
Host B
Host A
X
ACK=100
ACK=120

TCP fast retransmit
Host B
Host A
timeout
ACK=100
ACK=100
ACK=100
ACK=100
X
Seq=100, 20 bytes of
data
Receipt of three duplicate ACKs
indicates 3 segments received
after a missing segment – lost
segment is likely. So retransmit!
if sender receives 3 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

TCP flow control
application
process
TCP socket
receiver buffers
TCP
code
IP
code
receiver protocol stack
Q: What happens if network
layer delivers data faster than
application layer removes
data from socket buffers?
Network layer
delivering IP datagram
payload into TCP
socket buffers
from sender
Application removing
data from TCP socket
buffers

TCP flow control
application
process
TCP socket
receiver buffers
TCP
code
IP
code
from sender
buffers
receive window
flow control: # bytes
receiver willing to accept

TCP flow control
application
process
TCP socket
receiver buffers
TCP
code
IP
code
receiver controls sender, so
sender won’t overflow
receiver’s buffer by
transmitting too much, too fast
flow control
from sender
buffers

TCP flow control
 TCP receiver “advertises” free buffer
space in rwnd field in TCP header
• RcvBuffer size set via socket
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
buffered data
free buffer space
rwnd
RcvBuffer
TCP segment payloads
to application process
TCP receiver-side buffering

TCP flow control
 TCP receiver “advertises” free buffer
space in rwnd field in TCP header
• RcvBuffer size set via socket
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
flow control: # bytes receiver willing to accept
receive window
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 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();

Agreeing to establish a connection
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)

2-way handshake scenarios
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!

ESTAB
retransmit
req_conn(x
)
req_conn(x)
client
terminate
s
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)

client
terminate
s
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)

TCP 3-way handshake
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))

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

Transport Layer
 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
COMPSCI 453 Computer Networks
Professor Jim Kurose
College of Information and Computer Sciences
University of Massachusetts
Class textbook:
Computer Networking: A Top-
Down Approach (8th
ed.)
J.F. Kurose, K.W. Ross
Pearson, 2020
http://gaia.cs.umass.edu/kurose_ross
Video: 2020, J.F. Kurose, All Rights Reserved
Powerpoint: 1996-2020, J.F. Kurose, K.W. Ross, All Rights Reserved

TCP: Transport Control Protocol
 segment structure
 reliable data transfer
 sequence numbers
 ACKs
 timers

TCP sender (simplified)
wait
for
event
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum
L
retransmit not-yet-acked
segment with smallest
seq. #
start timer
timeout
if (y > SendBase) {
SendBase = y
/* SendBase–1: last cumulatively ACKed byte */
if (there are currently not-yet-acked segments)
start timer
else stop timer
}
ACK received, with ACK field value y
create segment, seq. #: NextSeqNum
pass segment to IP (i.e., “send”)
NextSeqNum = NextSeqNum + length(data)
if (timer currently not running)
start timer
data received from application above

3.5_TCP_video_slides_discover_rdt_protocol.pptx

More Related Content

Similar to 3.5_TCP_video_slides_discover_rdt_protocol.pptx

Recently uploaded

3.5_TCP_video_slides_discover_rdt_protocol.pptx

Editor's Notes