Transcript Lecture 7: Reliable Data Transfer

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:
network layer: data transfer
between end systems
transport layer: data
transfer between processes

application
transport
network
data link
physical
relies on, enhances, network
layer services
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
Similar issues at data link layer
Reliable Data Transfer
#3
Internet transport-layer protocols
 TCP : reliable, in-order delivery
Connection-Oriented




connection setup
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
Principles of Reliable data transfer
 important in app., transport, link layers
 Highly important networking topic!
 characteristics of unreliable channel will determine
complexity of reliable data transfer protocol (rdt)
Reliable Data Transfer
#5
Reliable data transfer: getting started
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 packet be lost
 Packet duplication:
 Can packets be duplicated in channel.
 Reordering of packets
 Is channel FIFO?
 Internet: Errors, Loss, Duplication, non-FIFO
 PTP Phys. Chan: Error, Loss only
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 L deliver_data(data_outj)
 For every i  L: data_ini = data_outi
 Liveness (needs assumptions):

For every i there exists a time T 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 machines (FSM) to specify
sender, receiver
state: when in this
“state”, next state
uniquely determined
by next event
state
1
event causing state transition
actions taken on state transition
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 of packets
 separate FSMs for sender, receiver:
 sender sends data into underlying channel
 receiver reads data from underlying channel
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
 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 (data, ACK and NACK) are:
Delivered in order (FIFO)
 No loss
 No duplication

 Data packets might get corrupt,
 and the corruption is detectable.
 ACK and NACK do not get corrupt.
 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
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)
New items written in red
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
Reliable Data Transfer
#15
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
 and the receiver will not
be able to identify the
duplication
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
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

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
Reliable Data Transfer
#19
rdt2.2: a NACK-free protocol
sender
FSM
 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
Reliable Data Transfer
#20
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
Q: how to deal with loss?
Proposal:


sender waits until
certain data or ACK
lost, then retransmits
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
Reliable Data Transfer
#21
rdt 3.0 assumptions on uc
 FIFO:

Data packets and Ack packets are delivered in
order.
 Errors and Loss:
 Data
and ACK packets might get corrupt or lost
 No duplication: but can handle it!
 Liveness:
 If
continuously sending packets, eventually, an
uncorrupted packet received.
Reliable Data Transfer
#22
rdt3.0 sender
Reliable Data Transfer
#23
rdt 3.0 receiver
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
rdt_rcv(rcvpkt)
&& corrupt(rcvpkt)
Extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK[0])
udt_send(ACK[0])
udt_send(ACK[1])
Wait for 0
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
udt_send(ACK[1])
rdt_rcv(rcvpkt)
&& corrupt(rcvpkt)
Wait for 1
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& has_seq1(rcvpkt)
Extract(rcvpkt,data)
deliver_data(data)
udt_send(ACK[1])
rdt_rcv(rcvpkt)
&& notcorrupt(rcvpkt)
&& has_seq0(rcvpkt)
udt_send(ACK[0])
Reliable Data Transfer
#24
rdt3.0 in action
Reliable Data Transfer
#25
rdt3.0 in action
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
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”
may receive duplicate ACKs (see receiver)
 timer points to the packet at base
 timeout(n): retransmit pkt n and all higher seq # pkts in window

Reliable Data Transfer
#32
GBN: sender extended FSM
/*for the packet at the new base*/
Reliable Data Transfer
#33
GBN: receiver extended FSM
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 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
GBN: Correctness
 Claim I (safety):
The receiver delivers the data in the correct order
 Proof: unbounded seq. num. QED

 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
#36
GBN: correctness - liveness
 Let:

base=k; expectedseqnum=m; nextseqnum=n;
 Observation: k ≤ m ≤ n
 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
#37
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.
Ack i<k
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
Not in send window with k
Corollary: Sufficient to use N+1 seq. num.
Reliable Data Transfer
#38
Selective Repeat
Reliable Data Transfer
#39
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
#40
Selective repeat: sender, receiver windows
Reliable Data Transfer
#41
Selective repeat
sender
data from above :
receiver
pkt n in [rcvbase, rcvbase+N-1]
 if next available seq # is
 send ACK(n)
timeout(n):
 in-order: deliver (also
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
deliver buffered, in-order
pkts), advance window to
next not-yet-received pkt
pkt n in
[rcvbase-N,rcvbase-1]
 send ACK(n)
otherwise:
 ignore
Reliable Data Transfer
#42
Selective repeat in action
Reliable Data Transfer
#43
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
#44
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
#45
Choosing the window size
 Small window size:

idle link (under-utilization).
 Large window size:
 Buffer space
 Delay after loss
 Ideal window size (assuming very low loss)
 RTT =Round trip time
 C = link capacity
 window size = RTT * C
 What happens with no loss?
Reliable Data Transfer
#46