Selective repeat

 receiver individually acknowledges all correctly

received pkts
 buffers pkts, as needed, for eventual in-order delivery
to upper layer
 sender only resends pkts for which ACK not
received
 sender timer for each unACKed pkt
 sender window
 N consecutive seq #’s
 limits seq #s of sent, unACKed pkts

Transport Layer 3-51

Selective repeat: sender, receiver windows

Transport Layer 3-52

1
 Selective repeat
sender receiver
data from above: pkt n in [rcvbase, rcvbase+N-1]
 if next available seq # in  send ACK(n)
window, send pkt  out-of-order: buffer
timeout(n):  in-order: deliver (also
 resend pkt n, restart deliver buffered, in-order
timer pkts), advance window to
next not-yet-received pkt
ACK(n) in [sendbase,sendbase+N]:
 mark pkt n as received
pkt n in [rcvbase-N,rcvbase-1]
 ACK(n)
 if n smallest unACKed
pkt, advance window base otherwise:
to next unACKed seq #  ignore

Transport Layer 3-53

Selective repeat 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, buffer,
012345678 rcv ack0, send pkt4 send ack3
012345678 rcv ack1, send pkt5 receive pkt4, buffer,
send ack4
record ack3 arrived receive pkt5, buffer,
send ack5
pkt 2 timeout
012345678 send pkt2
012345678 record ack4 arrived
012345678 rcv pkt2; deliver pkt2,
record ack5 arrived
012345678 pkt3, pkt4, pkt5; send ack2

Q: what happens when ack2 arrives?

Transport Layer 3-54

2
 sender window receiver window
Selective repeat: (after receipt) (after receipt)

dilemma 0123012 pkt0

pkt1
0123012 0123012
pkt2 0123012
example:
0123012
0123012
pkt3
 seq #’s: 0, 1, 2, 3 0123012
0123012
X
 window size=3 pkt0 will accept packet
with seq number 0
(a) no problem
 receiver sees no
difference in two receiver can’t see sender side.
scenarios! receiver behavior identical in both cases!
something’s (very) wrong!
 duplicate data
accepted as new in 0123012 pkt0
(b) 0123012 pkt1 0123012
0123012 pkt2 0123012
X 0123012
Q: what relationship X
between seq # size timeout
retransmit pkt0 X
and window size to 0123012 pkt0
will accept packet
avoid problem in (b)? with seq number 0
(b) oops!
Transport Layer 3-55

Chapter 3 outline
3.1 transport-layer
services
3.2 multiplexing and
demultiplexing
3.3 connectionless
transport: UDP
3.4 principles of reliable
data transfer
3.5 connection-oriented
transport: TCP
 segment structure
 reliable data transfer
 flow control
 connection management
3.6 principles of congestion
control
3.7 TCP congestion control

Transport Layer 3-56

3
 TCP: Overview RFCs: 793,1122,1323, 2018, 2581

 point-to-point:  full duplex data:

 one sender, one receiver  bi-directional data flow
 reliable, in-order byte in same connection
steam:  MSS: maximum segment
size
 no “message
boundaries”  connection-oriented:
 pipelined:  handshaking (exchange
of control msgs) inits
 TCP congestion and sender, receiver state
flow control set window before data exchange
size
 flow controlled:
 sender will not
overwhelm receiver
Transport Layer 3-57

TCP segment structure

32 bits
URG: urgent data counting
(generally not used) source port # dest port #
by bytes
sequence number of data
ACK: ACK #
valid acknowledgement number (not segments!)
head not
PSH: push data now len used
UAP R S F receive window
(generally not used) # bytes
checksum Urg data pointer
rcvr willing
RST, SYN, FIN: to accept
options (variable length)
connection estab
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)

Transport Layer 3-58

4
TCP seq. 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 rwnd

data
checksum urg pointer

window size
acknowledgements: N

seq # of next byte

expected from other side sender sequence number space
cumulative ACK
sent sent, not- usable not
Q: how receiver handles ACKed yet ACKed but not usable
out-of-order segments (“in-
flight”)
yet sent

A: TCP spec doesn’t say, incoming segment to sender

- up to implementor source port # dest port #
sequence number
acknowledgement number
A rwnd
checksum urg pointer

Transport Layer 3-59

TCP seq. numbers, ACKs

Host A Host B

User
types
‘C’ Seq=42, ACK=79, data = ‘C’
host ACKs
receipt of
‘C’, echoes
Seq=79, ACK=43, data = ‘C’ back ‘C’
host ACKs
receipt
of echoed
‘C’ Seq=43, ACK=80

simple telnet scenario

Transport Layer 3-60

5
TCP round trip time, timeout
Q: how to set TCP Q: how to estimate RTT?
timeout value?  SampleRTT: measured
time from segment
 longer than RTT transmission until ACK
 but RTT varies receipt
 too short: premature  ignore retransmissions
timeout, unnecessary  SampleRTT will vary, want
retransmissions estimated RTT “smoother”
 average several recent
 too long: slow reaction measurements, not just
to segment loss current SampleRTT

Transport Layer 3-61

TCP round trip time, timeout

EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT
 exponential weighted moving average
 influence of past sample decreases exponentially fast
 typical value:  = 0.125 RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

350

RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

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) Transport Layer 3-62
SampleRTT Estimated RTT

6
TCP round trip time, timeout
 timeout interval: EstimatedRTT plus “safety margin”
 large variation in EstimatedRTT -> larger safety margin
 estimate SampleRTT deviation from EstimatedRTT:
DevRTT = (1-)*DevRTT +
*|SampleRTT-EstimatedRTT|
(typically,  = 0.25)

TimeoutInterval = EstimatedRTT + 4*DevRTT

estimated RTT “safety margin”

Transport Layer 3-63

Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
3.2 multiplexing and  segment structure
demultiplexing  reliable data transfer
3.3 connectionless  flow control
transport: UDP  connection management
3.4 principles of reliable 3.6 principles of congestion
data transfer control
3.7 TCP congestion control

Transport Layer 3-64

7
TCP reliable data transfer
 TCP creates rdt service
on top of IP’s unreliable
service
 pipelined segments
 cumulative acks let’s initially consider
 single retransmission simplified TCP sender:
timer  ignore duplicate acks
 retransmissions  ignore flow control,
triggered by: congestion control
 timeout events
 duplicate acks

Transport Layer 3-65

TCP sender events:

data rcvd from app:
 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
timeout:
 retransmit segment
that caused timeout
 restart timer
ack rcvd:
 if ack acknowledges
previously unacked
segments
 update what is known
to be ACKed
 start timer if there are
still unacked segments

Transport Layer 3-66

8
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)
L start timer
NextSeqNum = InitialSeqNum wait
SendBase = InitialSeqNum for
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-67

TCP: retransmission scenarios

Host A Host B Host A Host B

SendBase=92
Seq=92, 8 bytes of data Seq=92, 8 bytes of data

Seq=100, 20 bytes of data

timeout

timeout

ACK=100
X
ACK=100
ACK=120

Seq=92, 8 bytes of data Seq=92, 8

SendBase=100 bytes of data
SendBase=120
ACK=100
ACK=120

SendBase=120

lost ACK scenario premature timeout

Transport Layer 3-68

9
TCP: retransmission scenarios
Host A Host B

Seq=92, 8 bytes of data

Seq=100, 20 bytes of data

timeout

ACK=100
X
ACK=120

Seq=120, 15 bytes of data

cumulative ACK
Transport Layer 3-69

TCP ACK generation [RFC 1122, RFC 2581]

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

Transport Layer 3-70

10
TCP fast retransmit
 time-out period often
relatively long: TCP fast retransmit
 long delay before if sender receives 3
resending lost packet ACKs for same data
 detect lost segments (“triple
(“triple duplicate
duplicate ACKs”),
ACKs”),
via duplicate ACKs. resend unacked
 sender often sends segment with smallest
many segments back- seq #
to-back
 likely that unacked
 if segment is lost, there segment lost, so don’t
will likely be many wait for timeout
duplicate ACKs.

Transport Layer 3-71

TCP fast retransmit

Host A Host B

Seq=92, 8 bytes of data

Seq=100, 20 bytes of data
X

ACK=100
timeout

ACK=100
ACK=100
ACK=100
Seq=100, 20 bytes of data

fast retransmit after sender

receipt of triple duplicate ACK
Transport Layer 3-72

11
Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
3.2 multiplexing and  segment structure
demultiplexing  reliable data transfer
3.3 connectionless  flow control
transport: UDP  connection management
3.4 principles of reliable 3.6 principles of congestion
data transfer control
3.7 TCP congestion control

Transport Layer 3-73

TCP flow control

application
application may process
remove data from application
TCP socket buffers ….
TCP socket OS
receiver buffers
… slower than TCP
receiver is delivering
(sender is sending) TCP
code

IP
flow control code
receiver controls sender, so
sender won’t overflow
receiver’s buffer by transmitting from sender
too much, too fast
receiver protocol stack

Transport Layer 3-74

12
TCP flow control
 receiver “advertises” free
buffer space by including to application process
rwnd value in TCP header
of receiver-to-sender
segments RcvBuffer buffered data
 RcvBuffer size set via
socket options (typical default rwnd free buffer space
is 4096 bytes)
 many operating systems
autoadjust RcvBuffer TCP segment payloads
 sender limits amount of
unacked (“in-flight”) data to receiver-side buffering
receiver’s rwnd value
 guarantees receive buffer
will not overflow
Transport Layer 3-75

Chapter 3 outline
3.1 transport-layer 3.5 connection-oriented
services transport: TCP
3.2 multiplexing and  segment structure
demultiplexing  reliable data transfer
3.3 connectionless  flow control
transport: UDP  connection management
3.4 principles of reliable 3.6 principles of congestion
data transfer control
3.7 TCP congestion control

Transport Layer 3-76

13
Connection Management
before exchanging data, sender/receiver “handshake”:
 agree to establish connection (each knowing the other willing
to establish connection)
 agree on connection parameters

application application

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 welcomeSocket.accept();
number");

Transport Layer 3-77

Agreeing to establish a connection

2-way handshake:
Q: will 2-way handshake
always work in
network?
Let’s talk
ESTAB  variable delays
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

Transport Layer 3-78

14
 Agreeing to establish a connection
2-way handshake failure scenarios:

choose x choose x
req_conn(x) req_conn(x)
ESTAB ESTAB
retransmit acc_conn(x) retransmit acc_conn(x)
req_conn(x) req_conn(x)

ESTAB ESTAB
data(x+1) accept
req_conn(x)
retransmit data(x+1)
data(x+1)
connection connection
client x completes server x completes server
client
terminates forgets x terminates forgets x
req_conn(x)

ESTAB ESTAB
data(x+1) accept
half open connection! data(x+1)
(no client!)
Transport Layer 3-79

TCP 3-way handshake

client state server state

LISTEN LISTEN
choose init seq num, x
send TCP SYN msg
SYNSENT SYNbit=1, Seq=x
choose init seq num, y
send TCP SYNACK
msg, acking SYN SYN RCVD
SYNbit=1, Seq=y
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

Transport Layer 3-80

15
TCP 3-way handshake: FSM

closed

Socket connectionSocket =
welcomeSocket.accept();

L Socket clientSocket =
SYN(x) newSocket("hostname","port
number");
SYNACK(seq=y,ACKnum=x+1)
create new socket for SYN(seq=x)
communication back to client listen

SYN SYN
rcvd sent

SYNACK(seq=y,ACKnum=x+1)
ESTAB ACK(ACKnum=y+1)
ACK(ACKnum=y+1)
L

Transport Layer 3-81

TCP: closing a 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 3-82

16
TCP: closing a connection
client state server state
ESTAB ESTAB
clientSocket.close()

FIN_WAIT_1 can no longer FINbit=1, seq=x

send but can
receive data CLOSE_WAIT
ACKbit=1; ACKnum=x+1
can still
FIN_WAIT_2 wait for server send data
close

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

Transport Layer 3-83

17