1. Chapter 6
Reliable Data
Transfer
Reliable Data Transfer

2. Transport Layer Our goals: Chapter 6:
understand principles behind transport layer services:
Multiplexing / demultiplexing data streams of several applications
reliable data transfer
flow control
congestion control
Chapter 6:
rdt principles
Chapter 7:
multiplex/ demultiplex
Internet transport layer protocols:
UDP: connectionless transport
TCP: connection-oriented transport
connection setup
data transfer
flow control
congestion control
Reliable Data Transfer

3. Transport services and protocols
provide logical communication between app’ processes running on different hosts
transport protocols run in end systems
transport vs network layer services:
transport layer: data transfer between end system processes
relies on, enhances, network layer services
network layer: data transfer between end systems
datalink layer: data transfer between connected NICs
issues similar to those of the transport layer (exc. cong.ctrl)
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
logical end-end transport
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
Reliable Data Transfer

4. Internet transport-layer protocols
TCP : reliable, in-order delivery Connection-Oriented
connection setup /teardown
error correction
flow control
congestion control
UDP unreliable, unordered delivery: Connectionless
simple extension of “best-effort” IP
services not available (in both protocols):
delay guarantees
bandwidth guarantees
application
transport
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
logical end-to-end transport
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
Reliable Data Transfer

5. Reliable data transfer: Setting
highly important networking topic!
here described on the Transport layer
also important in application and link layers
characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)
Reliable Data Transfer

6. Reliable data transfer: dramatis personæ
rdt_send(): called from above, (e.g., by app.). Passed data to
deliver to receiver upper layer
deliver_data(): called by rdt to deliver data to upper
send
side
receive
side
udt_send(): called by rdt,
to transfer packet over
unreliable channel to receiver
rdt_rcv(): called when packet arrives on rcv-side of channel
Reliable Data Transfer

7. Unreliable Channel Characteristics
Packet Errors:
packet content modified
Assumption: either no errors or detectable.
Packet loss:
Can packets be lost
Packet duplication:
Can packets be duplicated in channel.
Reordering of packets
Is channel FIFO?
Internet L3: Error, Loss, Duplication, non-FIFO
PTP Phys. Chan: only Error, Loss possible
Reliable Data Transfer

8. Specification Inputs from application:
sequence of rdt_send(data_ini)
Outputs to destination application:
sequence of deliver_data(data_outj)
Safety:
Assume deliver_data (data_outj), j L received
For every i  L: data_ini = data_outi
Liveness (needs assumptions):
For every i there exists j such that data_ini = data_outj
Reliable Data Transfer

9. Reliable data transfer: protocol model
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 machine (FSM) notation to specify sender, receiver actions; as follows:
event
actions
event causing state transition
actions taken on state transition
state 1
state: when in this “state”, next state uniquely determined by next event
state 2
event
actions
Reliable Data Transfer

10. Rdt1.0: reliable transfer over reliable channel
Assumption : underlying channel perfectly reliable
no bit errors
no loss, duplication or misordering of packets
separate FSMs for sender, receiver:
sender sends data into underlying channel
receiver reads data from underlying channel & delivers it
init
init
Wait for call from above
rdt_send( data)
Wait for call from below
rdt_rcv( packet)
packet = make_pkt (data)
udt_send (packet)
extract (packet, data)
deliver_data (data)
sender
receiver
Reliable Data Transfer

11. Rdt2.0: channel with bit errors
Assumption : underlying channel may flip bits in packet
but no data packets are lost/ duplicated/ misordered
add checksum field to detect bit errors
the question: how to recover from errors:
acknowledgements (ACKs) : receiver explicitly tells sender that packet received OK
negative acknowledgements (NAKs) : receiver explicitly tells sender that packet had errors
sender retransmits packet on receipt of NAK
new mechanisms in rdt2.0 (beyond rdt1.0):
error detection
receiver feedback: control msgs (ACK,NAK) rcvr ->sender
retransmission by sender
Reliable Data Transfer

12. uc 2.0: channel assumptions
Packets are:
Delivered in order (FIFO)
No loss
No duplication
Packets might get corrupt,
and the corruption is detectable.
Liveness assumption:
If continuously sending data packets, udt_send()
eventually, an uncorrupted data packet received.
Reliable Data Transfer

13. rdt2.0: FSM specification
sender
receiver
rdt_send (data)
rdt_rcv (rcvpkt) &&
corrupt (rcvpkt)
sndpkt = make_pkt (data, checksum)
udt_send (sndpkt)
init
udt_send (NAK)
rdt_rcv (rcvpkt) &&
isNAK (rcvpkt)
init
Wait for call from above
Wait for ACK or NAK
udt_send (sndpkt)
Wait for call from below
rdt_rcv (rcvpkt) && isACK (rcvpkt) L
rdt_rcv (rcvpkt) &&
notcorrupt (rcvpkt)
Notation:
Λ = No Action
&& = AND
|| = OR
New items written in red
extract (rcvpkt, data)
deliver_data (data)
udt_send (ACK)
Reliable Data Transfer

14. rdt2.0: in action (no errors)L
sender FSM
receiver FSM
Reliable Data Transfer

15. rdt2.0: in action (error scenario)L
sender FSM
receiver FSM
Qn: Can you find a problem rdt 2.0 ?
Reliable Data Transfer

16. rdt2.0 has a fatal flaw! What happens if ACK/NAK corrupted?
sender doesn’t know what happened at receiver!
must retransmit: BUT: possible duplicate
in rdt 2.0 receiver can’t identify the duplication
so: must find a way to handle duplicates
Handling duplicates:
sender adds a sequence number to each packet
sender retransmits current pkt if ACK/NAK garbled
with same sequence number
receiver discards (doesn’t deliver up) duplicate pkt
 rdt 2.1
Sender sends one packet,
then waits for receiver
response
stop and wait
Reliable Data Transfer

17. rdt2.1 handles garbled ACK/NAKs : Sender
rdt_send (data)
sndpkt = make_pkt (0, data, checksum)
udt_send (sndpkt)
init
rdt_rcv (rcvpkt) &&
( corrupt (rcvpkt) ||
isNAK (rcvpkt) )
Wait for ACK or NAK 0
Wait for call 0 from above
udt_send (sndpkt)
rdt_rcv (rcvpkt)
&& notcorrupt (rcvpkt)
&& isACK (rcvpkt)
rdt_rcv (rcvpkt)
&& notcorrupt (rcvpkt)
&& isACK (rcvpkt) L L
Wait for ACK or NAK 1
Wait for
call 1 from above
rdt_rcv (rcvpkt) &&
( corrupt (rcvpkt) ||
isNAK (rcvpkt) )
rdt_send (data)
sndpkt = make_pkt (1, data, checksum)
udt_send (sndpkt)
udt_send (sndpkt)
Reliable Data Transfer

18. rdt2.1 handles garbled ACK/NAKs: Receiver
rdt_rcv (rcvpkt) && notcorrupt (rcvpkt)
&& has_seq0 (rcvpkt)
extract (rcvpkt,data)
deliver_data (data)
sndpkt = make_pkt (ACK, chksum)
udt_send (sndpkt)
init
rdt_rcv (rcvpkt) && corrupt (rcvpkt)
rdt_rcv (rcvpkt) && corrupt (rcvpkt)
sndpkt = make_pkt (NAK, chksum)
udt_send (sndpkt)
sndpkt = make_pkt( NAK, chksum)
udt_send (sndpkt)
Wait for
0 from below
Wait for
1 from below
rdt_rcv (rcvpkt) &&
not corrupt (rcvpkt) &&
has_seq1(rcvpkt)
rdt_rcv (rcvpkt) &&
not corrupt (rcvpkt) &&
has_seq0 (rcvpkt)
sndpkt = make_pkt (ACK, chksum)
udt_send (sndpkt)
sndpkt = make_pkt (ACK, chksum)
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)
Reliable Data Transfer

19. rdt2.1: discussion Sender: seq # added to pkt
two seq. #’s (0,1) will suffice. Why?
must check if received ACK/NAK corrupted
twice as many states
state must “remember” whether “current” pkt has 0 or 1 seq. #
Receiver:
must check if received packet is duplicate
state indicates whether 0 or 1 is the expected packet sequence #
Note: receiver can not know if its last ACK/NAK received OK at sender
Note: we added sequence number to the data packets but NOT to the ACK/NAK; Ack doesn’t say which packet it acknowledges
Why is this sufficient?
Reliable Data Transfer

20. rdt2.2: a NACK-free protocol
same functionality as rdt2.1, using ACKs only
instead of NACK, receiver sends ACK for last pkt received OK
receiver must explicitly include in ACK the seq # of pkt being ACKed
duplicate ACK at sender results in same action as NACK: retransmit current pkt
sender
FSM
init
Note: L 1
Note: receiver FSM identical with 3.0 (below)
Reliable Data Transfer

21. rdt3.0: channels with errors and loss
New assumption: underlying channel can also lose packets (data or ACKs)
checksum, seq. #, ACKs, retransmissions will be of help, but not enough
Qn: how to deal with loss? Proposal:
sender waits until it’s certain that data or ACK is lost, then retransmits
Qn: Is this feasible?
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 on the sender side
ACK was required to include seq. # of acked packet already in 2.2
Reliable Data Transfer

22. rdt 3.0 assumptions on uc FIFO: Errors and Loss:
Data packets & Ack packets are delivered in order.
Errors and Loss:
Data and ACK packets might get corrupt or lost
No duplication in uc, but RDT can cause duplication
Note: rdt hides duplications and other errors from user layer
Liveness:
If continuously sending packets, eventually, an uncorrupted packet received.
Reliable Data Transfer

23. rdt3.0 : sender
init 1
Reliable Data Transfer

24. rdt3.0 : Receiver init 0 from below 1 from below
rdt_rcv (rcvpkt) && notcorrupt (rcvpkt)
&& has_seq0 (rcvpkt)
extract (rcvpkt,data)
deliver_data (data)
sndpkt = make_pkt (ACK0, chksum)
udt_send (sndpkt)
init
rdt_rcv (rcvpkt) && corrupt (rcvpkt)
rdt_rcv (rcvpkt) && corrupt (rcvpkt)
sndpkt = make_pkt (ACK1, chksum)
udt_send (sndpkt)
sndpkt = make_pkt( ACK0, chksum)
udt_send (sndpkt)
Wait for
0 from below
Wait for
1 from below
rdt_rcv (rcvpkt) &&
not corrupt (rcvpkt) &&
has_seq1(rcvpkt)
rdt_rcv (rcvpkt) &&
not corrupt (rcvpkt) &&
has_seq0 (rcvpkt)
sndpkt = make_pkt (ACK1, chksum)
udt_send (sndpkt)
sndpkt = make_pkt (ACK0, chksum)
udt_send( sndpkt)
rdt_rcv (rcvpkt) && notcorrupt (rcvpkt)
&& has_seq1(rcvpkt)
extract (rcvpkt,data)
deliver_data (data)
sndpkt = make_pkt (ACK1, chksum)
udt_send (sndpkt)
Reliable Data Transfer

25. rdt3.0 in action
Reliable Data Transfer

26. rdt3.0 in action rcv ACK1/ignore* rcv ACK0 send pkt1 * duplicate ACK
Reliable Data Transfer

27. Performance of rdt3.0 rdt3.0 works, but performance stinks
example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet: T
transmit =
8kb/pkt
10**9 b/sec
= 8 microsec
Utilization = U = =
8 microsec
msec
fraction of time
sender busy sending =
1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link
transport protocol limits use of physical resources!
Reliable Data Transfer

28. rdt3.0: Stop-and-Wait Operation
sender
receiver
first packet bit transmitted, t = 0
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
Reliable Data Transfer 28

29. 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
Reliable Data Transfer

30. Pipelining: increased utilization
sender
receiver
first packet bit transmitted, t = 0
last bit transmitted, t = L / R
first packet bit arrives
RTT
last bit of packet 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 (!)
3 = “window size” here
Qn: Can we get 100% utilization?
Reliable Data Transfer

31. Go Back N (GBN)
Reliable Data Transfer

32. Go-Back-N unbounded seq. num, starting at 0
Sender:
unbounded seq. num, starting at 0
window size = N : up to N consecutive unack’ed pkts allowed
Initialization
Receiver knows when to expect packet 0
ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK”
sender may receive duplicate ACKs (see receiver)
timer refers to the packet at base
timeout(n): retransmit pkt n and all higher seq # pkts in buffer
Reliable Data Transfer

33. GBN: extended FSM - sender
/*for the packet at the new base*/
Reliable Data Transfer

34. GBN: extended FSM - receiver
expectedseqnum = expectedseqnum+1
receiver simple:
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 data pkt:
discard (don’t buffer) -> no receiver buffering!
ACK pkt with highest in-order seq #
= highest received seq.num
Reliable Data Transfer

35. GBN in action window size = 4 Start timer 0
Stop timer 0, start timer 1
Stop timer 1, start timer 2
Reliable Data Transfer

36. Selective Repeat
Reliable Data Transfer

37. 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
individual sender timer for each unACKed pkt
sender window
N consecutive seq #’s
again limits seq #s of sent, unACKed pkts
Reliable Data Transfer

38. Selective repeat: sender, receiver windows
Reliable Data Transfer

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

40. Selective repeat in action
Reliable Data Transfer

41. Numbering range & Window size
So far packet numbers were unlimited
In practice we allow integers in [1, K]
Question is: Given window size N, what is the minimal value of K that will work?
Answer is:
For GBN we need K to be at least N+1
For SR we need K to be at least 2N
The justification for this is outlined in the next slides
Reliable Data Transfer

42. Optional: Correctness Discussion
Reliable Data Transfer

43. GBN: Correctness As usual we assume channel is FIFO Claim I (safety):
The receiver delivers the data in the correct order
Proof: unbounded seq. num. QED Qn: Why?
Claim I (seqnum):
In the receiver:
Value of expectedseqnum only increases (in broad sense)
In the sender:
The received ACK seqnum only increases (in broad sense).
This is why the sender does not need to test getacknum(rcvpkt) when updating variable base!
Reliable Data Transfer

44. GBN: correctness - liveness
Let: base=k; expectedseqnum=m; nextseqnum=n
Observation: k ≤ m ≤ n
k<m: m-k pkts received at destination; their acks not yet received by the sender
m<n: n-m pkts sent; not yet received at dest.
Claim (Liveness):
If k<m then eventually base ≥ m
If (k=m and m<n) then eventually:
receiver outputs data item m
Expectedseqnum ≥ m+1
Reliable Data Transfer

45. GBN - Bounding seq. num. Corollary: Sufficient to use N+1 seq. num.
Claim: After receiving Data k no Data i≤k-N is received.
After receiving ACK k no ACK i<k is received.(ass. FIFO)
Ack i<k impossible
Seq num only increases
Clearing a FIFO channel:
Data k
Ack k
Ack i<k
impossible
impossible
Data i<k-N
SENDER DISAMBIGUATION:
When sender receives ACK for packet k and starts sending k+1, then:
all ACKs in transit are at least k.
The sender keeps sending packets in [k+1,k+N] until it receives a new ACK (in [k+1,k+N]).
Therefore, as long as the last received ACK is k, there can be at most N+1 different ACKs arriving, each of them has a different meaning and k is the smallest of them
So if we number cyclically in the space of N+1 values, we can always regard k as the smallest one and make no mistake
RECEIVER DISAMBIGUATION:
Assume that the last packet accepted at destination was k, receiver knows that:
at the time sender sent packet k all the packets in the send buffer must have been > k-N
since packet number is counted mod (N+1), no retransmitted packet received after k was accepted can masquerade as k+1, since that would mean that packet k-N was sent after k, but they can not coexist in the send buffer.
since receiver cares only whether the packet received at this stage is k+1 or not, this closes the argument.
Data i<k-N impossible
Not in same send window with k
Corollary: Sufficient to use N+1 seq. num.
Reason: all we need is prevent taking an old pkt as a new one
Reliable Data Transfer

46. Selective Repeat - Correctness
Infinite seq. Num.
Safety: immediate from the seq. Num.
Liveness: Eventually data and ACKs get through.
Finite Seq. Num.
Idea: Re-use seq. Num.
Use less bits to encode them.
Number of seq. Num.:
At least N.
Needs more!
Reliable Data Transfer

47. 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) or
Discards in (b)
Q: what relationship between seq # size and window size?
When an ACK(k) received and base updates, the sender “knows” that no packets in transit with i<k-N (also i> k+N-1 not sent yet). Need at least 2N+1 seq #
(Max. seq# + 1)/2  window-size
Reliable Data Transfer