Principles of Reliable data transfer

important in app., transport, link layers

top-10 list of important networking topics!

characteristics of unreliable channel will determine complexity

of reliable data transfer protocol (rdt)
Transport Layer 3-1
Reliable data transfer: getting started
We’ll:
incrementally develop sender, receiver sides of
reliable data transfer protocol (rdt)
consider only unidirectional data transfer
but control info will flow on both directions!
use finite state machines (FSM) to specify
sender, receiver
event causing state transition
actions taken on state transition
state: when in this
“state” next state state state
1 event
uniquely determined 2
by next event actions

Transport Layer 3-2

Rdt1.0: reliable transfer over a reliable channel
underlying channel perfectly reliable
no bit errors
no loss of packets
separate FSMs for sender, receiver:
sender sends data into underlying channel
receiver read data from underlying channel

Wait for rdt_send(data) Wait for rdt_rcv(packet)

call from call from extract (packet,data)
above packet = make_pkt(data) below deliver_data(data)
udt_send(packet)

sender receiver

Transport Layer 3-3

Rdt2.0: channel with bit errors
underlying channel may flip bits in packet
checksum to detect bit errors
the question: how to recover from errors:
acknowledgements (ACKs): receiver explicitly tells sender that
pkt received OK
negative acknowledgements (NAKs): receiver explicitly tells
sender that pkt had errors
sender retransmits pkt on receipt of NAK
new mechanisms to handle bit errors
error detection
receiver feedback: control msgs (ACK,NAK) rcvr->sender
Retransmission

Transport Layer 3-4

rdt2.0 has a fatal flaw!
What happens if
ACK/NAK corrupted?
sender doesn’t know what
happened at receiver!
can’t just retransmit: possible
duplicate
Handling duplicates:
sender retransmits current
pkt if ACK/NAK garbled
sender adds sequence number
to each pkt
receiver discards (doesn’t
deliver up) duplicate pkt
stop and wait
Sender sends one packet,
then waits for receiver
response
Transport Layer 3-5
handling corrupted ACKs or
NAKs
Sender ---- receiver (packets loss at both sides
might lead to indefinite path)
enough checksum bits to allow the sender not
only to detect, but also to recover from, bit
errors.
the immediate problem for a channel that can corrupt
packets but not lose them is solved
resend the current data packet when it receives
a garbled ACK or NAK packet.
Duplicate packets emerges.
(old packet /new packet)
Transport Layer 3-6
solution
Sequence number in a received ACK or
the packet- NAK packet (whether
To check whether it garbled or not) was
is retransmission generated in
allow the receiver to response to its most
know whether the recently transmitted
sender is resending data packet.
the previously
transmitted packet

Transport Layer 3-7

rdt2.1: discussion
Sender: Receiver:
seq # added to pkt must check if received
two seq. #’s (0,1) will packet is duplicate
suffice. Why? state indicates whether 0
or 1 is expected pkt seq #
must check if received
ACK/NAK corrupted note: receiver can not
know if its last ACK/NAK
twice as many states
received OK at sender
state must “remember”
whether “current” pkt has
0 or 1 seq. #

Transport Layer 3-8

When an out-of- When a corrupted
order packet is packet is received,
received, the the receiver sends a
receiver sends a negative
positive acknowledgment
acknowledgment for duplicate ACKs
the packet it has identifies that the
received. receiver did not
correctly receive the
packet
Transport Layer 3-9
rdt2.2: a NAK-free protocol

same functionality as rdt2.1, using ACKs only

instead of NAK, receiver sends ACK for last pkt
received OK
receiver must explicitly include seq # of pkt being ACKed
duplicate ACK at sender results in same action as NAK:
retransmit current pkt

Transport Layer 3-10

rdt3.0: channels with errors and loss
Packet loss-?
How and what to do ?
New assumption:
underlying channel can
also lose packets (data
or ACKs)
checksum, seq. #, ACKs,
retransmissions will be of
help, but not enough
Approach: sender waits
“reasonable” amount of
time for ACK
 retransmits if no ACK
received in this time
 if pkt (or ACK) just delayed
(not lost):
 retransmission will be
duplicate, but use of seq.
#’s already handles this
 receiver must specify seq
# of pkt being ACKed
 requires countdown timer
Transport Layer 3-11
 Retransmission of the packet might be
done ( ack lost/ pkt lost)
 Sender waits for an amount of time then
starts retransmission.-But how long??????
 as long as a round-trip delay between the

+
sender and receiver amount of time is
needed to process a packet at the receiver
 Hence duplication of packets arises a data
packet was lost, an ACK was lost, or if the
packet or ACK was simply overly delayed

Transport Layer 3-12

Count down timer- time based
retransmission
start the timer each time a packet (either a
first-time packet or a retransmission) is
sent,
respond to a timer interrupt (taking
appropriate actions, and
stop the timer.
packet sequence numbers alternate between
0 and 1-------alternating bit protocol

Transport Layer 3-13

 Stop and Wait
• Simplest ARQ protocol
• Sender:
Sender Receiver
– Send a packet
– Stop and wait until an

Timeout
ACK arrives Time
– If received ACK, send
the next packet
– If timeout, ReTransmit
the same packet
• Receiver:
– When you receive a
packet correctly, send
an ACK
 Recovering from Error
Timeout

Timeout

Timeout
Time
Timeout

Timeout

Timeout
Packet lost ACK lost Early timeout

• Does this protocol work?

• When an ACK is lost or a early timeout occurs, how does the
receiver know whether the packet is a retransmission or a new
packet?
– Use sequence numbers: Both Packets and ACKs
Stop & Wait with Seq #s
Timeout

Timeout

Timeout
Time
Timeout

Timeout

Timeout
Packet lost ACK lost Early timeout

– Sequence # in packet is finite -- how big should it be?

• One bit – won’t send Pkt #1 until received ACK for Pkt #0
The Stop and Wait ARQ solves main three
problems, (lost data/ack/delay ack)

a high bandwidth connection and propagation

delay is also high >> is stop and wait
suitable???
How about throughput and utilization?

Transport Layer 3-17

Performance of rdt3.0

rdt3.0 works, but performance stinks

ex: 1 Gbps link, 15 ms prop. delay, 8000 bit packet:
L 8000 bits
dtrans   9
 8 microseconds
R 10 bps
U sender: utilization – fraction of time sender busy sending

U L/R .008
sender
= = = 0.00027
RTT + L / R 30.008 microsec
onds
1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link
network protocol limits use of physical resources!

Transport Layer 3-18

Pipelined protocols
Pipelining: sender allows multiple, “in-flight”, yet-to-
be-acknowledged pkts
 range of sequence numbers must be increased
 buffering at sender and/or receiver

 Two generic forms of pipelined protocols: go-Back-N,

selective repeat
Transport Layer 3-19
 Pipelining: increased utilization
sender receiver
first packet bit transmitted, t = 0
last bit transmitted, t = L / R

first packet bit arrives

RTT last packet bit arrives, send ACK
last bit of 2nd packet arrives, send ACK
last bit of 3rd packet arrives, send ACK
ACK arrives, send next
packet, t = RTT + L / R

Increase utilization
by a factor of 3!

U 3*L/R .024
sender
= = = 0.0008
RTT + L / R 30.008 microsecon
ds
Transport Layer 3-20
rdt3.0 in action

Transport Layer 3-21

rdt3.0 in action

Transport Layer 3-22

Pipelining Protocols
Go-back-N: overview
 sender: up to N
unACKed pkts in
pipeline
 receiver: only sends
cumulative ACKs
 doesn’t ACK pkt if
there’s a gap
 sender: has timer for
oldest unACKed pkt
 if timer expires:
retransmit all unACKed
packets
Selective Repeat: overview
 sender: up to N unACKed
packets in pipeline
 receiver: ACKs individual
pkts
 sender: maintains timer
for each unACKed pkt
 if timer expires: retransmit
only unACKed packet
Buffer size-
Window full
Transport Layer 3-23
Selective repeat: big picture
 Sender can have up to N unacked packets
in pipeline
 Rcvr acks individual packets
 Sender maintains timer for each unacked
packet
 When timer expires, retransmit only unack
packet

Transport Layer 3-24

Go-Back-N
Sender:
k-bit seq # in pkt header
“window” of up to N, consecutive unACKed pkts allowed

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

may receive duplicate ACKs (see receiver)
timer for each in-flight pkt
timeout(n): retransmit pkt n and all higher seq # pkts in window

Transport Layer 3-25

Sliding Window:
Generic Sender/Receiver States
Sender Receiver

Last ACK Received Last Packet Sent Next Packet Expected Last Packet Acceptable
(LAR) (LPS) (NPE) (LPA)

… … … …

Sender Window Size Receiver Window Size

Sent & Acked Sent Not Acked Received & Acked Acceptable Packet

OK to Send Not Usable Not Usable

Transport Layer 3-27
GBN: receiver extended FSM
default
udt_send(sndpkt) rdt_rcv(rcvpkt)
&& notcurrupt(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)
expectedseqnum++

ACK-only: always send ACK for correctly-received pkt

with highest in-order seq #
may generate duplicate ACKs
need only remember expectedseqnum
out-of-order pkt:
discard (don’t buffer) -> no receiver buffering!
Re-ACK pkt with highest in-order seq #
Transport Layer 3-28
GBN in
action

Transport Layer 3-29

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

Transport Layer 3-30

Selective repeat: sender, receiver windows

Transport Layer 3-31

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

Transport Layer 3-32

Selective repeat in action

Transport Layer 3-33

Transport Layer 3-34
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?
Transport Layer 3-35
 TCP: Overview RFCs: 793, 1122, 1323, 2018, 2581

point-to-point: full duplex data:

one sender, one receiver bi-directional data flow in
reliable, in-order byte same connection
steam: MSS: maximum segment
size
no “message boundaries”
connection-oriented:
pipelined:
handshaking (exchange of
TCP congestion and flow control msgs) init’s sender,
control set window size receiver state before data
send & receive buffers exchange
flow controlled:
sender will not overwhelm
application application
writes data reads data
socket socket

receiver
door door
TCP TCP
send buffer receive buffer
segment

Transport Layer 3-36

 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 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-37

 TCP seq. #’s and ACKs
Seq. #’s:
Host A Host B
 byte stream
“number” of first User
types
byte in segment’s ‘C’
data 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 ‘C’
handles out-of-order
segments
time
 A: TCP spec doesn’t
simple telnet scenario
say, - up to
implementer Transport Layer 3-38
End-to-end Protocols
Common properties that a transport protocol
can be expected to provide
 Guarantees message delivery
 Delivers messages in the same order they were
sent
 Delivers at most one copy of each message
 Supports arbitrarily large messages
 Supports synchronization between the sender
and the receiver
 Allows the receiver to apply flow control to the
sender
 Supports multiple application processes on each
host
End-to-end Protocols
Typical limitations of the network on which
transport protocol will operate
 Drop messages
 Reorder messages
 Deliver duplicate copies of a given message
 Limit messages to some finite size
 Deliver messages after an arbitrarily long delay
End-to-end Protocols
Challenge for Transport Protocols
Develop algorithms that turn the less-than-
desirable properties of the underlying network
into the high level of service required by
application programs
Reliable Byte Stream (TCP)
In contrast to UDP, Transmission Control
Protocol (TCP) offers the following services
Reliable
Connection oriented
Byte-stream service
TCP reliable data transfer
TCP creates rdt service retransmissions are
on top of IP’s unreliable triggered by:
service timeout events
pipelined segments duplicate ACKs
cumulative ACKs initially consider
TCP uses single simplified TCP sender:
ignore duplicate ACKs
retransmission timer
ignore flow control,
congestion control

Transport Layer 3-43

TCP Round Trip Time and 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
RTT computed only once
Q: how to estimate RTT?
 SampleRTT:
the amount of time
between when the segment
is sent (that is, passed to
IP) and when an
acknowledgment for the
segment is received.
ignore retransmissions
 SampleRTT will vary, want
estimated RTT “smoother”
Transport Layer 3-44
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 (as per RFC)

 Set timeout based on EstRTT

• TimeOut = 2 x EstRTT

Transport Layer 3-45

Original Algorithm

Problem
ACK does not really acknowledge a transmission
• It actually acknowledges the receipt of data
When a segment is retransmitted and then an
ACK arrives at the sender
• It is impossible to decide if this ACK should be
associated with the first or the second transmission
for calculating RTTs
Karn/Partridge Algorithm

Associating the ACK with (a) original transmission versus (b) retransmission

Do not sample RTT when retransmitting

Double timeout after each retransmission
TCP sender events:
data rcvd from app: timeout:
create segment with seq retransmit segment that
# caused timeout
seq # is byte-stream restart timer
number of first data ACK rcvd:
byte in segment if acknowledges
start timer if not already previously unACKed
running (think of timer segments
as for oldest unACKed update what is known to
segment) be ACKed
expiration interval: start timer if there are
TimeOutInterval – outstanding segments
computed from
EstimatedRTT and Transport Layer 3-48
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

Transport Layer 3-49

 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
Transport Layer 3-50
 TCP retransmission scenarios (more)
Host A Host B
timeout

X
loss

SendBase
= 120

time
Cumulative ACK scenario

Transport Layer 3-51

Doubling the Timeout Interval
 whenever the timeout event occurs, TCP
retransmits the not-yet acknowledged
segment with the smallest sequence
number
 Each time TCP retransmits, it sets the
next timeout interval to twice the previous
value, rather than deriving it from the last
EstimatedRTT and DevRTT

Transport Layer 3-52

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

Transport Layer 3-53

TCP RTT =30 msec
ACK comes after 26,32 and 24 msec
Determine the new RTT estimate. Use
smoothing factor = 0.9
Hint:
EstimatedRTT = (1- )*EstimatedRTT
+ *SampleRTT
0.9 * 30 + (1-0.9)* 26= 29.6 msec

Transport Layer 3-54