reliable data transfer

Reliable Data Transfer #1

Reliable Data Transfer

Transport LayerOur goals: understand

principles behind transport layer services: Multiplexing /

demultiplexing data streams of several applications

reliable data transfer flow control congestion control

Chapter 6: rdt principlesChapter 7: multiplex/ demultiplex Internet transport layer

protocols: UDP: connectionless

transport TCP: connection-oriented

transport• connection setup• data transfer• flow control• congestion control



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 relies on, enhances, network

layer services dataink layer: data transfer

between connected NICs issues similar to those of the

transport layer (exc. cong.ctrl)

application

transportnetworkdata linkphysical

application

transportnetworkdata linkphysical

networkdata linkphysical



networkdata linkphysicalnetwork

data linkphysical

logical end-end transport

Internet transport-layer protocols

TCP : reliable, in-order deliveryConnection-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

applicationtransportnetworkdata linkphysical

applicationtransportnetworkdata linkphysical




networkdata linkphysicalnetwork

data linkphysical

logical end-to-end transport



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: dramatis personæ

sendside

receiveside

rdt_send(): called from above, (e.g., by app.). Passed data to deliver to receiver upper layer

udt_send(): called by rdt,to transfer packet over unreliable channel to

receiver

rdt_rcv(): called when packet arrives on rcv-side of channel

deliver_data(): called by rdt to deliver data to

upper


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


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: protocol modelWe’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:

state1

state2

event causing state transitionactions taken on state transition

state: when in this “state”, next state

uniquely determined by

next event

eventactions

eventactions

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 & delivers it

packet = make_pkt (data)udt_send (packet)

Wait for call from above

rdt_send( data)

sender

init

extract (packet, data)deliver_data (data)

Wait for call from

below

rdt_rcv( packet)

receiver

init


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



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.

Notation:Λ = No Action&& = AND || = OR

New items written in red

rdt2.0: FSM specification

extract (rcvpkt, data)deliver_data (data)udt_send (ACK)

rdt_rcv (rcvpkt) && notcorrupt (rcvpkt)

udt_send (NAK)

rdt_rcv (rcvpkt) && corrupt (rcvpkt)

Wait for call from

below

receiversender

rdt_rcv (rcvpkt) && isNAK (rcvpkt)Wait for

call from above

sndpkt = make_pkt (data, checksum)udt_send (sndpkt)

rdt_rcv (rcvpkt) && isACK (rcvpkt)

udt_send (sndpkt)

Wait for ACK or

NAK

rdt_send (data)

init

init



rdt2.0: in action (no errors)

sender FSM receiver FSM

rdt2.0: in action (error scenario)

sender FSM receiver FSM

Reliable Data Transfer #15Qn: Can you find a problem rdt

2.0 ?

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


rdt2.1 handles garbled ACK/NAKs : Sender

Wait for

call 0 from above

sndpkt = make_pkt (0, data, checksum)udt_send (sndpkt)

rdt_send (data)

Wait for ACK or

NAK 0 udt_send (sndpkt)

rdt_rcv (rcvpkt) && ( corrupt (rcvpkt) ||isNAK (rcvpkt) )

sndpkt = make_pkt (1, data, checksum)udt_send (sndpkt)

rdt_send (data)

rdt_rcv (rcvpkt) && notcorrupt (rcvpkt) && isACK (rcvpkt)

udt_send (sndpkt)

rdt_rcv (rcvpkt) && ( corrupt (rcvpkt) ||isNAK (rcvpkt) )

rdt_rcv (rcvpkt) && notcorrupt (rcvpkt) && isACK (rcvpkt)

Wait for call 1 from

above

Wait for ACK or NAK 1

init


Wait for 0 from below

sndpkt = make_pkt( NAK, chksum)udt_send (sndpkt)

rdt_rcv (rcvpkt) && not corrupt (rcvpkt) && has_seq0 (rcvpkt)

rdt_rcv (rcvpkt) && notcorrupt (rcvpkt) && has_seq1(rcvpkt)

extract (rcvpkt,data)deliver_data (data)sndpkt = make_pkt (ACK, chksum)udt_send (sndpkt)

Wait for 1 from below

rdt_rcv (rcvpkt) && notcorrupt (rcvpkt) && has_seq0 (rcvpkt)

extract (rcvpkt,data)deliver_data (data)sndpkt = make_pkt (ACK, chksum)udt_send (sndpkt)


sndpkt = make_pkt (ACK, chksum)udt_send( sndpkt)

rdt_rcv (rcvpkt) && not corrupt (rcvpkt) && has_seq1(rcvpkt)


sndpkt = make_pkt (ACK, chksum)udt_send (sndpkt)

sndpkt = make_pkt (NAK, chksum)udt_send (sndpkt)

rdt2.1 handles garbled ACK/NAKs: Receiver

init


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 #19


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

senderFSM

Note:

0

1

init


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


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.


rdt3.0 sender

0

1


rdt_rcv(rcvpkt)&& notcorrupt(rcvpkt)&& has_seq1(rcvpkt) rdt_rcv(rcvpkt)

&& notcorrupt(rcvpkt)&& has_seq1(rcvpkt)

rdt_rcv(rcvpkt)&& notcorrupt(rcvpkt)&& has_seq0(rcvpkt)

rdt 3.0 receiver

rdt_rcv(rcvpkt)&& corrupt(rcvpkt)

udt_send(ACK[1])

udt_send(ACK[1])

Extract(rcvpkt,data)deliver_data(data)udt_send(ACK[1])

udt_send(ACK[0])

udt_send(ACK[0])

Extract(rcvpkt,data)deliver_data(data)udt_send(ACK[0])

rdt_rcv(rcvpkt)&& corrupt(rcvpkt)

rdt_rcv(rcvpkt)&& notcorrupt(rcvpkt)&& has_seq0(rcvpkt)

Wait for 0 Wait for 1


rdt3.0 in action


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

10**9 b/sec= 8 microsec

Utilization = U = =8 microsec

30.016 msecfraction of time

sender busy sending = 0.00027

1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link

transport protocol limits use of physical resources!

rdt3.0: Stop-and-Wait Operation

first packet bit transmitted, t = 0

sender receiver

RTT

last packet bit transmitted, t = L / R

first packet bit arrives

last packet bit arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R

U sender

= .008

30.016 = 0.027%

%microseconds

L / R

RTT + 2L/ R =


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


Pipelining: increased utilization

first packet bit transmitted, t = 0

sender receiver

RTT

last bit transmitted, t = L / R

first packet bit arriveslast bit of packet arrives, send ACK

ACK arrives, send next packet, t = RTT + L / R

last bit of 2nd packet arrives, send ACKlast bit of 3rd packet arrives, send ACK

Increase utilizationby a factor of 3 (!)3 = “window size” here


Go Back N (GBN)


Go-Back-NSender: unbounded seq. num, starting at 0 window size = N : up to N consecutive unack’ed pkts allowedInitialization 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

windowReliable Data Transfer #32

GBN: extended FSM - sender

/*for the packet at the new base*/

Reliable Data Transfer

#33

GBN: extended FSM - receiver

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 pkt: discard (don’t buffer) -> no receiver buffering! ACK pkt with highest in-order seq #

expectedseqnum = expectedseqnum+1

= highest received seq.num


GBN inaction

windowsize = 4

Start timer 0

Stop timer 0, start timer 1

Stop timer 1, start timer 2


Selective Repeat


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


Selective repeat: sender, receiver windows


Selective repeat

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 #

senderpkt n є[rcvbase, rcvbase+N-1]

send ACK(n) out-of-order: buffer in-order: deliver (deliver

all buffered, in-order pkts), advance window start to next not-yet-received pkt

pkt n є[rcvbase-N,rcvbase-1]

send ACK(n)

otherwise: ignore

receiver


Selective repeat in action


Choosing the window size

Small window size: idle link (under-utilization).

Large window size: Buffer space Delay after loss (only with GBN version)

Ideal window size (assuming very low loss) RTT =Round trip time C = link capacity [bits/s] window size = RTT * C [bits/RTT]

Qn: What happens with no loss?


Lecture 3#42

Optional: Correctness Discussion

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!


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


GBN - Bounding seq. num.

Clearing a FIFO channel:

Data k

Ack k

impossible

Data i<k-N

Ack i<k

impossible

Claim: After receiving Data k no Data i≤k-N is received.

After receiving ACK k no ACK i<k is received.(ass. FIFO)

Corollary: Sufficient to use N+1 seq. num.

Data i<k-NNot in send window with k

Ack i<kSeq num only

increases


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!


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

Documents

reliable transfer

reliable channelassumption

transport layer services

transport services

end systemstransport

transport layeralso

packet loss

state transitionactions