Transcript Lecture 7: Reliable Data Transfer

Chapter 6
Reliable Data
Transfer
Reliable Data Transfer
#1
Transport Layer
Our goals:
 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
#2
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
network
data link
physical
network
data link
physical
application
transport
network
data link
physical
Reliable Data Transfer
#3
Internet transport-layer protocols
 TCP : reliable, in-order delivery
Connection-Oriented




connection setup /teardown
error correction
flow control
congestion control
application
transport
network
data link
physical
 UDP unreliable, unordered delivery:
Connectionless

simple extension of “best-effort” IP
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
network
data link
physical
 services not available
(in both protocols):
 delay guarantees
 bandwidth guarantees
application
transport
network
data link
physical
Reliable Data Transfer
#4
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
#5
Reliable data transfer: dramatis personæ
rdt_send(): called from above,
(e.g., by app.). Passed data to
deliver to receiver upper layer
send
side
udt_send(): called by rdt,
to transfer packet over
unreliable channel to receiver
deliver_data(): called by
rdt to deliver data to upper
receive
side
rdt_rcv(): called when packet
arrives on rcv-side of channel
Reliable Data Transfer
#6
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
#7
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
#8
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
state: when in this
“state”, next state
uniquely determined
by next event
event causing state transition
actions taken on state transition
state
1
event
actions
state
2
Reliable Data Transfer
#9
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)
packet = make_pkt (data)
udt_send (packet)
sender
Wait for
call from
below
rdt_rcv( packet)
extract (packet, data)
deliver_data (data)
receiver
Reliable Data Transfer
#10
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
#11
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
#12
rdt2.0: FSM specification
receiver
sender
init
rdt_send (data)
sndpkt = make_pkt (data, checksum)
udt_send (sndpkt)
rdt_rcv (rcvpkt) &&
isNAK (rcvpkt)
Wait for
Wait for
call from
ACK or
udt_send (sndpkt)
above
NAK
rdt_rcv (rcvpkt) && isACK (rcvpkt)
L
Notation:
Λ = No Action
&& = AND
|| = OR
New items written in red
rdt_rcv (rcvpkt) &&
corrupt (rcvpkt)
init
udt_send (NAK)
Wait for
call from
below
rdt_rcv (rcvpkt) &&
notcorrupt (rcvpkt)
extract (rcvpkt, data)
deliver_data (data)
udt_send (ACK)
Reliable Data Transfer
#13
rdt2.0: in action (no errors)
L
sender FSM
receiver FSM
Reliable Data Transfer
#14
rdt2.0: in action (error scenario)
L
sender FSM
receiver FSM
Qn: Can you find a problem rdt 2.0 ?
Reliable Data Transfer
#15
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
stop and wait
Sender sends one packet,
then waits for receiver
response
Reliable Data Transfer
#16
rdt2.1 handles garbled ACK/NAKs : Sender
rdt_send (data)
init
rdt_rcv (rcvpkt)
&& notcorrupt (rcvpkt)
&& isACK (rcvpkt)
sndpkt = make_pkt (0, data, checksum)
udt_send (sndpkt)
rdt_rcv (rcvpkt) &&
Wait for
call 0 from
above
rdt_rcv (rcvpkt)
&& notcorrupt (rcvpkt)
&& isACK (rcvpkt)
L
rdt_rcv (rcvpkt) &&
( corrupt (rcvpkt) ||
isNAK (rcvpkt) )
udt_send (sndpkt)
( corrupt (rcvpkt) ||
isNAK (rcvpkt) )
udt_send (sndpkt)
Wait for
ACK or
NAK 0
L
Wait for
ACK or
NAK 1
Wait for
call 1 from
above
rdt_send (data)
sndpkt = make_pkt (1, data, checksum)
udt_send (sndpkt)
Reliable Data Transfer
#17
rdt2.1 handles garbled ACK/NAKs: Receiver
rdt_rcv (rcvpkt) && notcorrupt (rcvpkt)
&& has_seq0 (rcvpkt)
init
rdt_rcv (rcvpkt) && corrupt (rcvpkt)
extract (rcvpkt,data)
deliver_data (data)
sndpkt = make_pkt (ACK, chksum)
udt_send (sndpkt)
rdt_rcv (rcvpkt) && corrupt (rcvpkt)
sndpkt = make_pkt (NAK, chksum)
udt_send (sndpkt)
rdt_rcv (rcvpkt) &&
not corrupt (rcvpkt) &&
has_seq1(rcvpkt)
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_seq0 (rcvpkt)
sndpkt = make_pkt (ACK, chksum)
sndpkt = make_pkt (ACK, chksum)
udt_send (sndpkt)
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
#18
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
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
state must “remember”
whether “current” pkt
has 0 or 1 seq. #
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
#19
rdt2.2: a NACK-free protocol
 same functionality as
sender
FSM
rdt2.1, using ACKs only
 instead of NACK,
init
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
0
Note:
L
1
Note: receiver FSM identical with 3.0 (below)
Reliable Data Transfer
#20
rdt3.0: channels with errors and loss
New assumption:
underlying channel can
also lose packets (data
or ACKs)
Approach: sender waits
“reasonable” amount of
time for ACK
 retransmits if no ACK
received in this time
checksum, seq. #, ACKs,
retransmissions will be of  if pkt (or ACK) just delayed
help, but not enough
(not lost):
 retransmission will be
Qn: how to deal with loss?
duplicate, but use of seq.
Proposal:
#’s already handles this
 sender waits until it’s
 receiver must specify seq
certain that data or ACK
# of pkt being ACKed
is lost, then retransmits
 requires countdown timer
 Qn: Is this feasible?
on the sender side

Reliable Data Transfer
#21
rdt 3.0 assumptions on uc
 FIFO:

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
#22
rdt3.0 : sender
init
0
1
Reliable Data Transfer
#23
rdt3.0 : Receiver
rdt_rcv (rcvpkt) && notcorrupt (rcvpkt)
&& has_seq0 (rcvpkt)
extract (rcvpkt,data)
deliver_data (data)
sndpkt = make_pkt (ACK0, chksum)
udt_send (sndpkt)
rdt_rcv (rcvpkt) && corrupt (rcvpkt)
init
rdt_rcv (rcvpkt) && corrupt (rcvpkt)
sndpkt = make_pkt (ACK1, chksum)
udt_send (sndpkt)
rdt_rcv (rcvpkt) &&
not corrupt (rcvpkt) &&
has_seq1(rcvpkt)
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_seq0 (rcvpkt)
sndpkt = make_pkt (ACK1, chksum)
sndpkt = make_pkt (ACK0, chksum)
udt_send (sndpkt)
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
#24
rdt3.0 in action
Reliable Data Transfer
#25
rdt3.0 in action
rcv ACK1/ignore*
rcv ACK0
send pkt1
* duplicate ACK
Reliable Data Transfer
#26
Performance of rdt3.0
 rdt3.0 works, but performance stinks
 example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet:
Ttransmit =
8kb/pkt
= 8 microsec
10**9 b/sec
8 microsec
fraction of time
=
= 0.00027
Utilization = U = sender busy sending
30.016 msec


1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link
transport protocol limits use of physical resources!
Reliable Data Transfer
#27
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
U
sender
=
L/R
RTT + 2L/R
=
.008
30.016
= 0.027%
%microse
conds
Reliable Data Transfer
#28
Pipelined protocols
Pipelining: sender allows multiple, “in-flight”, yet-tobe-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
#29
Pipelining: increased utilization
sender
receiver
first packet bit transmitted, t = 0
last bit transmitted, t = L / R
RTT
first packet bit arrives
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
#30
Go Back N (GBN)
Reliable Data Transfer
#31
Go-Back-N
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
#32
GBN: extended FSM - sender
/*for the packet at the new base*/
Reliable Data Transfer
#33
GBN: extended FSM - receiver
expectedseqnum = expectedseqnum+1
receiver simple:
= highest received seq.num
 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 #
Reliable Data Transfer
#34
GBN in Start timer 0
action
window
size = 4
Stop timer 0, start timer 1
Stop timer 1, start timer 2
Reliable Data Transfer
#35
Selective Repeat
Reliable Data Transfer
#36
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
#37
Selective repeat: sender, receiver windows
Sender
Receiver
Reliable Data Transfer
#38
Selective repeat
sender
data from above :
receiver
pkt n є[rcvbase, rcvbase+N-1]
 if next available seq # is
 send ACK(n)
timeout(n):
 in-order: deliver (deliver all
in window, send pkt
 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 #
 out-of-order: buffer
buffered, in-order pkts in
buffer), advance window
start to next not-yetreceived pkt
pkt n є[rcvbase-N,rcvbase-1]
 send ACK(n)
otherwise:
 ignore
Reliable Data Transfer
#39
Selective repeat in action
Reliable Data Transfer
#40
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
#41
Optional: Correctness Discussion
Reliable Data Transfer
#42
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
#43
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
#44
GBN - Bounding 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
Clearing a FIFO channel:
Seq num only
Ack k
Ack i<k
increases
impossible
Data i<k-N Data k
impossible
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
#45
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
#46
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?
Reliable Data Transfer
#47