Professional Documents
Culture Documents
Chapter 3 v8.0
Chapter 3 v8.0
Transport Layer
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
Computer Networking: A
Top-Down Approach
8th edition
Jim Kurose, Keith Ross
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
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
demultiplexing transport
• reliable data transfer • TCP congestion control
• flow control
• congestion control
local or
• sender: breaks application messages regional ISP
▪ processes = kids
▪ app messages = letters in
envelopes
▪ transport protocol = Ann and Bill
who demux to in-house siblings
▪ network-layer protocol = postal
service
Sender:
application ▪ is passed an application- application
app. msg
layer message
transport ▪ determines segment TThhtransport
app. msg
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
physical physical
Receiver:
application ▪ receives segment from IP application
▪ checks header values
transport
app. msg ▪ extracts application-layer transport
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
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
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
local or
▪ UDP: User Datagram Protocol regional ISP
transport transport
network link network
link physical link
physical physical
network
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
transport transport
network link network
link physical link
physical physical
Hnnetwork
Ht HTTP msg
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
transport transport
network link network
link physical link
physical physical
transport
network
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
transport transport
network link network
link physical link
physical physical
Hn Ht HTTP msg
transport
network
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
transport transport
network link network
link physical link
physical physical
application
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
transport
transport transport
network
network link network
link physical link
physical physical
▪ HTTP/3
▪ if reliable transfer needed over UDP (e.g., HTTP/3):
▪ add needed reliability at application layer
▪ add congestion control at application layer
application application
transport transport
(UDP)
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
(UDP)
network (IP) network (IP)
link link
physical physical
physical physical
data to/from
UDP segment format application layer
Transmitted: 5 6 11
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
Received: 4 6 11
receiver-computed sender-computed
checksum
= checksum (as received)
wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
sum 1 0 1 1 1 0 1 1 1 0 1 1 1 1 0 0
checksum 0 1 0 0 0 1 0 0 0 1 0 0 0 0 1 1
Note: when adding numbers, a carryout from the most significant bit needs to be
added to the result
* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/
Transport Layer: 3-33
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
Even though
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
wraparound 1 1 0 1 1 1 0 1 1 1 0 1 1 1 0 1 1
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!
sending receiving
process process
application data data
transport
reliable channel
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
sender-side of receiver-side
reliable service abstraction reliable data of reliable data
transfer protocol transfer protocol
transport
network
unreliable channel
sending receiving
process process
application data data
transport
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
sender-side of receiver-side
Complexity of reliable data reliable data
transfer protocol
of reliable data
transfer protocol
transfer protocol will depend
(strongly) on characteristics of transport
network
unreliable channel (lose, unreliable channel
corrupt, reorder data?)
reliable service implementation
sending receiving
process process
application data data
transport
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
sender-side of receiver-side
reliable data of reliable data
Sender, receiver do not know transfer protocol transfer protocol
the “state” of each other, e.g.,
was a message received? transport
network
▪ unless communicated via a unreliable channel
message
reliable service implementation
unreliable channel
udt_send(): called by rdt rdt_rcv(): called when packet
to transfer packet over Bi-directional communication over arrives on receiver side of
unreliable channel to receiver unreliable channel channel
Transport Layer: 3-41
Reliable data transfer: getting started
We will:
▪ incrementally develop sender, receiver sides of reliable data transfer
protocol (rdt)
▪ consider only unidirectional data transfer
• but control info will flow in both directions!
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt) &&
&& notcorrupt(rcvpkt)
isACK(rcvpkt)
&& isACK(rcvpkt)
L
L
Wait for Wait for
ACK or call 1 from
rdt_rcv(rcvpkt) NAK 1 above
&& (corrupt(rcvpkt) ||
isNAK(rcvpkt) ) rdt_send(data)
udt_send(sndpkt)
Wait for Wait for
rdt_rcv(rcvpkt) && 0 from 1 from rdt_rcv(rcvpkt) &&
not corrupt(rcvpkt) && below below not corrupt(rcvpkt) &&
has_seq1(rcvpkt) has_seq0(rcvpkt)
sndpkt = make_pkt(ACK, chksum) sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt) udt_send(sndpkt)
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK, chksum)
udt_send(sndpkt)
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
rdt_rcv(rcvpkt) && && isACK(rcvpkt,0)
(corrupt(rcvpkt) || L
has_seq1(rcvpkt)) Wait for receiver FSM
0 from
udt_send(sndpkt) below fragment
rdt_rcv(rcvpkt) && notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
extract(rcvpkt,data)
deliver_data(data)
sndpkt = make_pkt(ACK1, chksum)
udt_send(sndpkt) Transport Layer: 3-55
rdt3.0: channels with errors and loss
New channel assumption: underlying channel can also lose
packets (data, ACKs)
• checksum, sequence #s, ACKs, retransmissions will be of help …
but not quite enough
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
rdt_send(data)
sndpkt = make_pkt(1, data, checksum)
udt_send(sndpkt)
start_timer
loss
ack1 send ack1
rcv ack1
send pkt0 pkt0
rcv pkt0 timeout
ack0 send ack0 resend pkt1 pkt1
rcv pkt1
ack1 send ack1
rcv ack1
send pkt0 pkt0
(a) no loss rcv pkt0
ack0 send ack0
stop and wait
sender sends one packet, then
waits for receiver response (b) packet loss
Transport Layer: 3-60
rdt3.0 in action
sender receiver
sender receiver send pkt0
pkt0
rcv pkt0
send pkt0 pkt0 send ack0
ack0
rcv pkt0 rcv ack0
ack0 send ack0 send pkt1 pkt1
rcv ack0 rcv pkt1
send pkt1 pkt1 send ack1
rcv pkt1
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
ack1
ack1 send ack1
X timeout
loss resend pkt1
timeout
pkt1 rcv pkt1
resend pkt1 pkt1
rcv pkt1 rcv ack1 (detect duplicate)
send pkt0 pkt0 send ack1
(detect duplicate)
ack1 send ack1 ack1 rcv pkt0
rcv ack1 rcv ack1 send ack0
send pkt0 pkt0 (ignore) ack0
rcv pkt0
ack0 send ack0 pkt1
L 8000 bits
Dtrans = R = 9 = 8 microsecs
10 bits/sec
L/R L/R
Usender=
RTT + L / R
.008 RTT
=
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
30.008
= 0.00027
U 3L / R .0024
sender = = = 0.00081
RTT + L / R 30.008
rcv_base
Not received
Transport Layer: 3-68
Go-Back-N in action
sender window (N=4) sender receiver
012345678 send pkt0
012345678 send pkt1
012345678 send pkt2 receive pkt0, send ack0
012345678 send pkt3 Xloss receive pkt1, send ack1
(wait)
receive pkt3, discard,
rcv ack0, send pkt4 (re)send ack1
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
012345678
012345678 rcv ack1, send pkt5 receive pkt4, discard,
(re)send ack1
ignore duplicate ACK receive pkt5, discard,
(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
012345678
012345678 rcv ack1, send pkt5
receive pkt4, buffer,
record ack3 arrived send ack4
receive pkt5, buffer,
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
pkt0
(after receipt)
a dilemma!
0123012
0123012 pkt1 0123012
0123012 pkt2 0123012
0123012
example: 0123012 pkt3
X
▪ seq #s: 0, 1, 2, 3 (base 4 counting)
0123012
pkt0 will accept packet
with seq number 0
▪ window size=3 (a) no problem
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
0123012 pkt0
0123012 pkt1 0123012
0123012 pkt2 X 0123012
X 0123012
X
timeout
retransmit pkt0
0123012 pkt0
will accept packet
with seq number 0
(b) oops!
Transport Layer: 3-74
sender window receiver window
Selective repeat: (after receipt)
pkt0
(after receipt)
a dilemma!
0123012
0123012 pkt1 0123012
0123012 pkt2 0123012
0123012
example: 0123012 pkt3
X
▪ seq #s: 0, 1, 2, 3 (base 4 counting) ▪ receiver can’t
0123012
pkt0 will accept packet
see sender side with seq number 0
▪ window size=3 (a) no problem
▪ receiver
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
behavior
identical in both
cases!
▪0something’s
123012 pkt0
Q: what relationship is needed 0(very)
1 2 3 0 1wrong!
2 pkt1 0123012
pkt2 X
between sequence # size and 0123012
X
0123012
0123012
window size to avoid problem X
timeout
in scenario (b)? retransmit pkt0
0123012 pkt0
will accept packet
with seq number 0
(b) oops!
Transport Layer: 3-75
Chapter 3: roadmap
▪ Transport-layer services
▪ Multiplexing and demultiplexing
▪ Connectionless transport: UDP
▪ Principles of reliable data transfer
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
window size
Acknowledgements: N
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
User types‘C’
Seq=42, ACK=79, data = ‘C’
host ACKs receipt
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
unnecessary retransmissions
▪ SampleRTT will vary, want
▪ too long: slow reaction to estimated RTT “smoother”
segment loss • average several recent
measurements, not just current
SampleRTT
350
RTT (milliseconds)
300
250
RTT (milliseconds)
200
sampleRTT
150
EstimatedRTT
100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)
time (seconds)
SampleRTT Estimated RTT Transport Layer: 3-82
TCP round trip time, timeout
▪ timeout interval: EstimatedRTT plus “safety margin”
• large variation in EstimatedRTT: want a larger safety margin
TimeOutInterval = EstimatedRTT + 4*DevRTT
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
* Check out the online interactive exercises for more examples: http://gaia.cs.umass.edu/kurose_ross/interactive/
Transport Layer: 3-83
TCP Sender (simplified)
event: data received from event: timeout
application ▪ retransmit segment that
caused timeout
▪ create segment with seq #
▪ restart timer
▪ seq # is byte-stream number of
first data byte in segment
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
SendBase=92
Seq=92, 8 bytes of data Seq=92, 8 bytes of data
timeout
ACK=100
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
X
ACK=100
ACK=120
SendBase=120
ACK=100
X
ACK=120
timeout
Receipt of three duplicate ACKs
indicates 3 segments received Seq=100, 20 bytes of data
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
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
network network
OK
ESTAB
▪ retransmitted messages (e.g.,
req_conn(x)) due to message
loss
choose x
req_conn(x) ▪ message reordering
acc_conn(x)
ESTAB ▪ can’t “see” other side
ESTAB
choose x
req_conn(x)
ESTAB
acc_conn(x)
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
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)
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
ESTAB
req_conn(x)
connection
client x completes server
terminates forgets x
ESTAB
acc_conn(x)
Problem: half open
connection! (no client)
Transport Layer: 3-99
2-way handshake scenarios
choose x
req_conn(x)
ESTAB
retransmit acc_conn(x)
req_conn(x)
ESTAB
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
data(x+1) accept
data(x+1)
retransmit
data(x+1)
connection
x completes server
client
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
send TCP SYN msg
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
1. On belay?
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
2. Belay on.
3. Climbing.
LAST_ACK
FINbit=1, seq=y
TIMED_WAIT can no longer
send data
ACKbit=1; ACKnum=y+1
timed wait
for 2*max CLOSED
segment lifetime
CLOSED
Host B
R/2
Q: What happens as
arrival rate lin lout
delay
throughput:
approaches R/2?
lin R/2 lin R/2
maximum per-connection large delays as arrival rate
throughput: R/2 lin approaches capacity
Transport Layer: 3-107
Causes/costs of congestion: scenario 2
▪ one router, finite buffers
▪ sender retransmits lost, timed-out packet
• application-layer input = application-layer output: lin = lout
• transport-layer input includes retransmissions : l’in lin
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
R R
throughput: lout
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
R R
no buffer space!
R R
throughput: lout
full buffers
when sending at
▪ sender knows when packet has been dropped: R/2, some packets
only resends if packet known to be lost are needed
retransmissions
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
R R
throughput: lout
to un-needed
full buffers – requiring retransmissions retransmissions
▪ but sender timer can time out prematurely,
sending two copies, both of which are delivered when sending at
R/2, some packets
are retransmissions,
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
including needed
Host A lin : original data lin
and un-needed
duplicates, that are
R/2
timeout
copy l'in: original data, plus delivered!
retransmitted data
R R
throughput: lout
to un-needed
full buffers – requiring retransmissions retransmissions
▪ but sender timer can time out prematurely,
sending two copies, both of which are delivered when sending at
R/2, some packets
are retransmissions,
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
including needed
and un-needed
lin R/2 duplicates, that are
delivered!
“costs” of congestion:
▪ more work (retransmission) for given receiver throughput
▪ unneeded retransmissions: link carries multiple copies of a packet
• decreasing maximum achievable throughput
retransmitted data
finite shared
output link buffers
Host D
lout
Host C
lin’ R/2
throughput: lout
lin R/2
delay
R/2
lin R/2
lout
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
throughput:
throughput
lin R/2 R/2
throughput: lout
effective throughput
R/2
lin
lout
wasted for packets lost downstream
lin’ R/2
router
▪ may indicate congestion level or
explicitly set sending rate
• e.g., TCP ECN, ATM, DECbit protocols
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
available but ~
cwnd
ACKed sent, but not- TCP rate ~ bytes/sec
yet ACKed not used RTT
(“in-flight”) last byte sent
RTT
• initially cwnd = 1 MSS
• double cwnd every RTT
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
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-124
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
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
time
t0 t1 t2 t3 t4
Transport Layer: 3-127
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
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
source destination
application application
TCP TCP
network network
link link
physical physical
packet queue almost
never empty, sometimes
overflows packet (loss)
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 */
Transport Layer: 3-130
Delay-based TCP congestion control
▪ congestion control without inducing/forcing loss
▪ maximizing throughput (“keeping the just pipe full… ”) while keeping
delay low (“…but not fuller”)
▪ a number of deployed TCPs take a delay-based approach
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
▪ involves both IP (IP header ECN bit marking) and TCP (TCP header C,E bit marking)
source TCP ACK segment
destination
application application
TCP ECE=1
TCP
network network
link link
physical physical
ECN=10 ECN=11
IP datagram
Transport Layer: 3-132
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
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
bottleneck
TCP connection 2 router
capacity R
Is TCP fair?
A: Yes, under idealized
loss: decrease window by factor of 2 assumptions:
congestion avoidance: additive increase ▪ same RTT
loss: decrease window by factor of 2
congestion avoidance: additive increase ▪ fixed number of sessions
only in congestion
avoidance
Connection 1 throughput R
Transport Layer: 3-134
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
congestion control parallel connections between two
hosts
▪ instead use UDP:
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
transfers) pipeline
Wireless networks Loss due to noisy wireless links, mobility;
TCP treat this as congestion loss
Long-delay links Extremely long RTTs
Data center networks Latency sensitive
Background traffic flows Low priority, “background” TCP flows
Network IP IP
TCP handshake
(transport layer) QUIC handshake
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
data
TLS handshake
(security)
data
GET GET
HTTP
GET QUIC QUIC QUIC QUIC QUIC QUIC
encrypt encrypt encrypt encrypt encrypt encrypt
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
• congestion control
▪ two network-layer
▪ instantiation, implementation chapters:
on the Internet • data plane
• UDP • control plane
• TCP
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
Transport Layer: 3-144
Go-Back-N: receiver extended FSM
any other event
udt_send(sndpkt) rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
L && 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)
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
expectedseqnum++
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
}
Transport Layer: 3-146
TCP 3-way handshake FSM
closed
Socket connectionSocket =
welcomeSocket.accept();
L Socket clientSocket =
newSocket("hostname","port number");
SYN(x)
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
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)
L
3 W
avg TCP throughput = 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
Copyright® 1996-2020, J.F Kurose and K.W. Ross, All Rights Reserved
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