Announcement

• Homework 1 graded
• Homework 2 out
– Due in a week, 1/30
• Project 2 problems
– Minet can only compile w/ old version of gcc
(2.96).
– Only tlab-login has that version
– Statically compile it and run on other Tlab
machines to avoid overload
 Review of Previous Lecture
• Reliable transfer protocols
– rdt2.1: sender, handles garbled ACK/NAKs
– rdt2.2: a NAK-free protocol
– rdt3.0: channels with errors and loss
– Pipelined protocols
• Go-back-N

Some slides are in courtesy of J. Kurose and K. Ross

 Outline
• Reliable transfer protocols
– Pipelined protocols
• Selective repeat
• Connection-oriented transport: TCP
– Overview and segment structure
– Reliable data transfer
– Flow control
– Connection management
• TCP congestion control (if time allowed)
 Go-Back-N
Sender:
• k-bit seq # in pkt header
• “window” of up to N, consecutive unack’ed pkts allowed

• ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK”

– may deceive duplicate ACKs (see receiver)
• Single timer for all in-flight pkts
• timeout(n): retransmit pkt n and all higher seq # pkts in window
 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
– again limits seq #s of sent, unACKed pkts
Selective repeat: sender, receiver windows
 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 timer deliver buffered, in-order
pkts), advance window to
ACK(n) in [sendbase,sendbase+N]: next not-yet-received pkt

• mark pkt n as received pkt n in [rcvbase-N,rcvbase-1]

• if n smallest unACKed pkt, • ACK(n)

advance window base to next
unACKed seq # otherwise:
• ignore
Selective repeat in action
 Selective repeat:
dilemma
• Example:
• seq #’s: 0, 1, 2, 3
• window size=3
• receiver sees no
difference in two
scenarios!
• incorrectly passes
duplicate data as new in (a)
• Q: what relationship
between seq # size and
window size?
 Outline
• Reliable transfer protocols
– Pipelined protocols
• Selective repeat
• Connection-oriented transport: TCP
– Overview and segment structure
– Reliable data transfer
– Flow control
– Connection management
 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581

• point-to-point: • full duplex data:

– one sender, one receiver – bi-directional data flow
in same connection
• reliable, in-order byte – MSS: maximum segment
steam: size
– no “message boundaries” • connection-oriented:
• pipelined: – handshaking (exchange
of control msgs) init’s
– TCP congestion and flow sender, receiver state
control set window size before data exchange
• send & receive buffers • flow controlled:
application
writes data
application
reads data – sender will not
overwhelm receiver
socket socket
door door
TCP TCP
send buffer receive buffer
segment
 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
UA P R S F Receive window
(generally not used) # bytes
checksum Urg data pnter
rcvr willing
RST, SYN, FIN: to accept
Options (variable length)
connection estab
(setup, teardown
commands)
application
Internet data
checksum (variable length)
(as in UDP)
 TCP seq. #’s and ACKs
Seq. #’s:
Host A Host B
– byte stream
“number” of first User
byte in segment’s types
data ‘C’
host ACKs
receipt of
ACKs:
‘C’, echoes
– seq # of next byte back ‘C’
expected from
other side
host ACKs
– cumulative ACK receipt
of echoed
Q: how receiver handles
‘C’
out-of-order segments
– A: TCP spec doesn’t
say, - up to time
implementor simple telnet scenario
 TCP Round Trip Time and Timeout
Q: how to set TCP Q: how to estimate RTT?
timeout value? • SampleRTT: measured time
• longer than RTT from segment transmission
– but RTT varies until ACK receipt
• too short: – ignore retransmissions
premature timeout • SampleRTT will vary, want
– unnecessary estimated RTT “smoother”
retransmissions
– average several recent
• too long: slow measurements, not just
reaction to segment current SampleRTT
loss
 TCP Round Trip Time and Timeout
EstimatedRTT = (1- )*EstimatedRTT + *SampleRTT

• Exponential weighted moving average

• influence of past sample decreases exponentially fast
• typical value:  = 0.125
 Example RTT estimation:
RTT: gaia.cs.umass.edu to fantasia.eurecom.fr

350

300

250
RTT (milliseconds)

200

150

100
1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106
time (seconnds)

SampleRTT Estimated RTT

 TCP Round Trip Time and Timeout
Setting the timeout
• EstimtedRTT plus “safety margin”
– large variation in EstimatedRTT -> larger safety margin

• first estimate of how much SampleRTT deviates from

EstimatedRTT:
DevRTT = (1-)*DevRTT +
*|SampleRTT-EstimatedRTT|

(typically,  = 0.25)

Then set timeout interval:

TimeoutInterval = EstimatedRTT + 4*DevRTT

 Outline
• Reliable transfer protocols
– Pipelined protocols
• Selective repeat
• Connection-oriented transport: TCP
– Overview and segment structure
– Reliable data transfer
– Flow control
– Connection management
 TCP reliable data transfer
• TCP creates rdt • Retransmissions are
service on top of IP’s triggered by:
unreliable service – timeout events
• Pipelined segments – duplicate acks

• Cumulative acks • Initially consider

simplified TCP sender:
• TCP uses single – ignore duplicate acks
retransmission timer – ignore flow control,
congestion control
 TCP sender events:
data rcvd from app: timeout:

• Create segment with • retransmit segment that

seq # caused timeout

• seq # is byte-stream • restart timer

number of first data Ack rcvd:
byte in segment
• If acknowledges previously
• start timer if not unacked segments
already running (think – update what is known to be
of timer as for oldest acked
unacked segment) – start timer if there are
outstanding segments
• expiration interval:
TimeOutInterval
• Difference from GBN?
NextSeqNum = InitialSeqNum
SendBase = InitialSeqNum

loop (forever) { TCP

sender
switch(event)

event: data received from application above

create TCP segment with sequence number NextSeqNum (simplified)
if (timer currently not running)
start timer
pass segment to IP Comment:
NextSeqNum = NextSeqNum + length(data)
• SendBase-1: last
event: timer timeout cumulatively
retransmit not-yet-acknowledged segment with ack’ed byte
smallest sequence number Example:
start timer • SendBase-1 = 71;
y= 73, so the rcvr
event: ACK received, with ACK field value of y wants 73+ ;
if (y > SendBase) { y > SendBase, so
SendBase = y
that new data is
if (there are currently not-yet-acknowledged segments)
start timer acked
}

} /* end of loop forever */

 TCP: retransmission scenarios
Host A Host B Host A Host B

Seq=92 timeout
timeout

X
loss

Sendbase
= 100

Seq=92 timeout
SendBase
= 120

SendBase
= 100 SendBase
= 120 premature timeout
time time
lost ACK scenario
 TCP retransmission scenarios (more)
Host A Host B
timeout

X
loss

SendBase
= 120

time
Cumulative ACK scenario
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 startsat lower end of gap
 Fast Retransmit
• Time-out period often
relatively long:
– long delay before
resending lost packet
• Detect lost segments
via duplicate ACKs.
– Sender often sends many
segments back-to-back
– If segment is lost, there
will likely be many
duplicate ACKs.
• If sender receives 3
ACKs for the same
data, it supposes that
segment after ACKed
data was lost:
– fast retransmit: resend
segment before timer
expires
 Fast retransmit algorithm:

event: ACK received, with ACK field value of y

if (y > SendBase) {
SendBase = y
if (there are currently not-yet-acknowledged segments)
start timer
}
else {
increment count of dup ACKs received for y
if (count of dup ACKs received for y = 3) {
resend segment with sequence number y
}

a duplicate ACK for fast retransmit

already ACKed segment