Reliable Data Transfer

Reliable Data Transfer #1

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

networkdata 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

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

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

extract (packet, data)deliver_data (data)

Wait for call from

rdt_rcv( packet)

receiver

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

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

rdt_send (data)

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

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

Wait for ACK or NAK 1

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

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

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

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])

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

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

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

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

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

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

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

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

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

1 Reliable Data Transfer. 2 r Problem: Reliability Want an abstraction of a reliable link even though packets can be corrupted or get lost r Solution:

Lecture 7: Reliable Data Transfer

Online Coding for Reliable Data Transfer in Lossy Wireless Sensor

Principles of Reliable Data Transfer. Reliable Delivery Making sure that the packets sent by the sender are correctly and reliably received by the receiver

Transport Layer3-1 Data Communication and Networks Lecture 5 Transport Protocols: Multiplexing and Reliable Data Transfer October 7, 2004

CPSC 441: Reliable Transport1 Reliable Data Transfer Instructor: Carey Williamson Office: ICT 740 Email: carey@cpsc.ucalgary.cacarey@cpsc.ucalgary.ca Class

Basics: Network Classiﬁcationmarbach/COURSES/CSC358_S14/l11.pdfBasics: Network Classiﬁcation Network Architecture Reliable Data Transfer Delay Models Implementation: Protocol Design

Reliable high-performance data transfer via Globus Online

CS 552 Reliable Data Transfer R. Martin Credit slides from I. Stoica, C. Jin, M. Mitzenmacher

Transport Layer 3-1 ECE 5650 TL: Reliable Data Transfer

CS348: Computer Networks Principles of Reliable Data Transfer

8: Principles of Reliable Data Transfer

Reliable file transfer across a 10 megabit ethernet

STREAM CONTROL TRANSMISSION PROTOCOL (SCTP). SCTP service model connection oriented reliable data transfer - no loss - no duplicates - data integrity

Data Communication Principles - Mississippi State Universityweb.cse.msstate.edu/~ramkumar/dcpj22.pdfData Communication Channels Delays and Switching Reliable Data Transfer A Systems

Workﬂow Automation Based on OSI Job Transfer and Manipulation · Transfer and Manipulation ... tably since reliable data transfer services with su cient geographical spans could

PROVEN RELIABLE IN CRITICAL SYSTEMS Space... · 2019-10-30 · PROVEN RELIABLE IN CRITICAL SYSTEMS ... Therefore, cables must supply power and transfer data at all times without ever

Reliable, wireless data transfer in a maritime environmentdynamic-positioning.com/proceedings/dp2014/Sensors... · 2015. 5. 27. · Arne Rinnan Sensors Reliable, wireless data transfer

Reliable Data Transfer

1 Ch. 7 : Internet Transport Protocols. 3-2 TCP reliable data transfer r TCP creates reliable service on top of IP’s unreliable service r pipelined segments