Principles of Reliable Data

Transfer
 Reliable Delivery
• Making sure that the packets sent by the sender are
correctly and reliably received by the receiver amid
network errors, i.e., corrupted/lost packets
– Can be implemented at LL, NL or TL of the protocol stack.
Totally a design choice

• When and why should this be used?

– Link Layer
• Rarely done over twisted-pair or fiber optic links
• Usually done over lossy links (wireless) for performance
improvement (versus correctness) in P2P links
– Network/Transport Layers
• Necessary if the application requires the data to be reliably
delivered to the receiver, e.g., file transfer
 Reliable Delivery: Service Model
… 4 3 2 1 … 4 3 2 1

RDT_Send Deliver_Data

Reliable Data Transfer Reliable Data Transfer

Protocol (Sender Side) Protocol (Receiver Side)
UDT_Send RDT_Receive
unreliable channel

Reliable, In-order Delivery

– Reliable, In-order delivery

• Typically done when reliability is implemented at the
transport layer, e.g., TCP
• Example application: File transfer
 Reliable Delivery: Assumptions
We’ll:
• Consider only unidirectional data transfer
– A sender sending packets to a receiver
– Bidirectional communication is a simple extension,
where there are 2 sender/receiver pairs

• Start with simple a protocol and make it complex

as we continue
 RDT over Unreliable Channel
… 4 3 2 1 … 4 3 2 1

RDT_Send Deliver_Data

Reliable Data Transfer Reliable Data Transfer

Protocol (Sender Side) Protocol (Receiver Side)
UDT_Send RDT_Receive
Unreliable channel

• Channel may flip bits in packets/lose packets

– The received packet may have been corrupted during
transmission, or dropped at an intermediate router due
to buffer overflow

• The question: how to recover from errors?

• ACKs, NACKs, Timeouts… Next
 RDT over Unreliable Channel
• Two fundamental mechanisms to accomplish
reliable delivery over Unreliable Channels
– Acknowledgements (ACK), Negative ACK (NACK)
• Small control packets (header without any data) that a
protocol sends back to its peer saying that it has received
an earlier packet (positive ACK) or that it has not received a
packet (NACK).
• Sent by the receiver to the sender
– Timeouts
• Set by the sender for each transmitted packet
• If an ACK is received before the timer expires, then the
packet has made it to the receiver
• If the timeout occurs, the sender assumes that the packet
is lost (corrupted) and retransmits the packet
 ARQ
• The general strategy of using ACKs (NACKs)
and timeouts to implement reliable delivery is
called Automatic Repeat reQuest (ARQ)

• 3 ARQ Mechanisms for Reliable Delivery

– Stop and Wait
– Concurrent Logical Channels
– Sliding Window
 Stop and Wait
• Simplest ARQ protocol
• Sender:
Sender Receiver
– Send a packet
P ac k e
– Stop and wait until an t

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

Timeout

Timeout
AC K C K
A
Time
Packe Packe Packe
t t t
Timeout

Timeout

Timeout
AC K
A CK ACK

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
Pk t 0 Pk t 0
Timeout Pkt 0

Timeout

Timeout
ACK 0 0
A CK
Time
Pkt 0 Pkt 0 Pkt 0
Timeout

Timeout

Timeout
ACK 0
ACK 0 ACK 0 Pkt 1
Pkt 1 Pkt 1

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
 Performance of Stop and Wait
• Can only send one packet per round trip
• example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:
sender receive
first packet bit transmitted, t = 0 r
last packet bit transmitted, t = L / R

first packet bit arrives

RTT last packet bit arrives, send
ACK

ACK arrives, send next

packet, t = RTT + L / R

U L/R .008
= = = 0.00027
sender 30.008
RTT + L / R microsec
onds
– 1KB pkt every 30 msec -> 33kB/sec throughput over 1 Gbps link
– network protocol limits use of physical resources!
 Pipelining: Increasing Utilization
• Pipelining: sender allows multiple, “in-flight”, yet-to-be-acknowledged
pkts without waiting for first to be ACKed to keep the pipe full
– Capacity of the Pipe = RTT * BW
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
 Sliding Window Protocols
• Reliable, in-order delivery of packets

• Sender can send “window” of up to N,

consecutive unack’ed packets
• Receiver makes sure that the packets are
delivered in-order to the upper layer

• 2 Generic Versions
– Go-Back-N
– Selective Repeat
 Sliding Window:
Generic Sender/Receiver States
Sender
Sender Receiver
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

 Sliding Window- Sender Side
• The sender maintains 3 variables
– Sender Window Size (SWS)
• Upper bound on the number of in-flight packets
– Last Acknowledgement Received (LAR)
– Last Packet Sent (LPS)
– We want LPS – LAR <= SWS

<= SWS

LAR LPS
 Sliding Window- Receiver Side
• The receiver maintains 3 variables
– Receiver Window Size (RWS)
• Upper bound on the number of buffered packets
– Last Packet Acceptable (LPA)
– Next Packet Expected (NPE)
– We want LPS – NPE + 1 <= RWS

<= RWS

NPE LPA
 Go-Back-N
Sender
Sender Receiver
Receiver
Last ACK Received Last Packet Sent Next Packet Expected Last Packet Acceptable
(LAR) (LPS) (NPE) (LPA)

… … … …

SWS = N
RWS = 1 packet

Sent & Acked Sent Not Acked Received & Acked Acceptable Packet

OK to Send Not Usable Not Usable

• SWS = N: Sender can send up to N consecutive unack’ed pkts

• RWS = 1: Receiver has buffer for just 1 packet
• Always sends ACK for correctly-rcvd pkt with highest in-order seq #
– Cumulative ACK
• Out-of-order pkt:
– discard & re-ACK pkt with highest in-order seq #
 Go-Back-N: Sender Actions
• Data From Above:
– Send packets as long as LPS-LAR <= SWS

• ACK(k): An ACK with “seqno = k” arrives:

– If k > LAR then, increase LAR until LAR hits a packet
for which ACK has not arrived yet, or LAR == LPS
– Send packet(s) as long as LPS-LAR <= SWS
– Associate a timer with the oldest packet sent
• Single timer for all packets in transit

• Timeout:
– Retransmit ALL packets that have been previously sent,
but not yet ACKed
• Therefore the name Go-Back-N
 Go-Back-N: Receiver Actions
• A packet with “seqno” arrives:
– If seqno == NPE then // in-order packet
• Deliver the packet to the upper layer
• Send an ACK for pkt# = seqno
• This is called “cumulative ACK” scheme
– ACKs not only the current packet, but also all packets before it

– If seqno != NPE then // out of order packet

• Since sequence # of the last packet received is NPE – 1,
send an ACK for pkt# = NPE-1
• Still using “cumulative ACK” scheme.
GBN in action (SWS = 4)
 GBN: Last Word
• Why use GBN?
– Very simple receiver

• Why NOT use GBN?

– Throwing away out-of-order packets at the receiver
results in extra transmissions, thus lowering the
channel utilization:
• The channel may become full of retransmissions of old
packets rather than useful new packets

– Can we do better?
• Yes: Buffer out-of-order packets at the receiver and do
Selective Repeat (Retransmissions) at the sender
 Selective Repeat
Sender
Sender Receiver
Receiver
Last ACK Received Last Packet Sent Next Packet Expected Last Packet Acceptable
(LAR) (LPS) (NPE) (LPA)

… … … …

SWS = N RWS = N

Sent & Acked Sent Not Acked Received & Acked Acceptable Packet

OK to Send Not Usable Not Usable

• SWS = RWS = N consecutive packets: Sender can send up to N

consecutive unack’ed pkts, Receiver can buffer up to N consecutive packets
• 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
 Selective repeat
sender
data from above :
• if next available seq # in
window, send pkt
timeout(k):
• resend pkt k, restart
timer
ACK(k) in [LAR+1, LPS]
• Mark pkt “k” as received
• if k == LAR +1 then,
advance LAR to next
unACKed pkt #
receiver
pkt k in [NPE, LPA]
• send ACK(k)
• out-of-order (k != NPE):
– buffer
• in-order (k == NPE):
– deliver (also deliver
buffered, in-order pkts),
advance NPE to next not-
yet-received pkt
• pkt k in [NPE-N, LPA-1]
– Send ACK(k)
otherwise:
• ignore
Selective repeat in action
 Selective Repeat: Sequence Numbers
• How large do sequence numbers need to be?
– Must be able to detect wrap-around
– Depends on sender/receiver window size
• E.g.
– Assume SWS = RWS = 7. Also assume that we use 3-bit
sequence numbers, i.e., 0..7
– Sender sends frames 0..6
• Assume receiver received all these frames successfully BUT all
ACKs are lost
• Receiver expects 7,0..5
• Sender timeouts and retransmits old 0..6
• Receiver receives these but assumes these are new frames!!
• It turns out that the sending window size can be no
more than half as big as the number of available
sequence numbers
– WS <= (MaxSeqNo +1)/2
 Sliding Window: Last Word
• Go-Back-N and Selective Repeat are NOT the
only sliding Window protocol alternatives

• Other variations exist:

– Let SWS = RWS = N and use cumulative ACKs
• Simplifies the sender: Can have a single timer instead of a
timer for each packet in transit
• This is in fact what TCP does!

– Let SWS = RWS = N, and use Negative ACKs

• Can be used when the channel is pretty reliable, i.e., packet
loss is very rare
• Only notify the sender when something goes wrong
– …
 SWS = RWS = 4 with cumulative ACKs
RWS = 4

NPE = 5 LPA =8

• Assume NPE = 5 and RWS = 4  LPA = 8

• Assume frames 6 and 7 arrive.
– They will be buffered, BUT no ACK will be sent since frame 5 is
yet to arrive.
– Frames 6 and 7 are said to arrive “out of order”
– Receiver sends ACK for pkt #4
• If frame 5 now arrives because it may have been lost
and retransmitted by the sender or it may have been
simply delayed
– The receiver will then ACK frame 7 (cumulative ACK) and sets
NPE to 8 and LPA to 11