Reliable Data Transfer#1#1 Reliable Data Transfer

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

#3#3 Transport services and protocols r provide logical communication between app’ processes running on different hosts r transport protocols run in end systems r transport vs network layer services: r network layer: data transfer between end systems r transport layer: data transfer between processes m relies on, enhances, network layer services application transport network data link physical 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 logical end-end transport Similar issues at data link layer

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

#5#5 Principles of Reliable data transfer r important in app., transport, link layers r Highly important networking topic! r characteristics of unreliable channel will determine complexity of reliable data transfer protocol (rdt)

Reliable Data Transfer#6#6 Reliable data transfer: getting started send side receive side 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

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

Reliable Data Transfer#8#8 Specification r Inputs from application: m sequence of rdt_send(data_in i ) r Outputs to destination application: m sequence of deliver_data(data_out j ) r Safety: m Assume L deliver_data(data_out j ) m For every i  L: data_in i = data_out i r Liveness (needs assumptions): m For every i there exists a time T such that data_in i = data_out j

Reliable Data Transfer#9#9 Reliable data transfer: protocol model We’ll: r incrementally develop sender, receiver sides of reliable data transfer protocol (rdt) r consider only unidirectional data transfer m but control info will flow on both directions! r use finite state machines (FSM) to specify sender, receiver state 1 state 2 event causing state transition actions taken on state transition state: when in this “state”, next state uniquely determined by next event event actions

Rdt1.0: reliable transfer over reliable channel r Assumption : underlying channel perfectly reliable m no bit errors m no loss of packets r separate FSMs for sender, receiver: m sender sends data into underlying channel m receiver reads data from underlying channel 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 Reliable Data Transfer#10

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

Reliable Data Transfer#12 uc 2.0: channel assumptions r Packets (data, ACK and NACK) are: m Delivered in order (FIFO) m No loss m No duplication r Data packets might get corrupt, m and the corruption is detectable. m ACK and NACK do not get corrupt. r Liveness assumption: m If continuously sending data packets, udt_send() m 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 receiver sender 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 Reliable Data Transfer#13

Reliable Data Transfer#14 rdt2.0: in action (no errors) sender FSMreceiver FSM 

rdt2.0: in action (error scenario) sender FSMreceiver FSM  Reliable Data Transfer#15

rdt2.0 has a fatal flaw! What happens if ACK/NAK corrupted? r sender doesn’t know what happened at receiver! r can’t just retransmit: possible duplicate m and the receiver will not be able to identify the duplication Handling duplicates: r sender adds a sequence number to each packet r sender retransmits current pkt if ACK/NAK garbled m with same sequence number r receiver discards (doesn’t deliver up) duplicate pkt Sender sends one packet, then waits for receiver response stop and wait Reliable Data Transfer#16

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 Reliable Data Transfer #17

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) rdt_rcv (rcvpkt) && corrupt (rcvpkt) sndpkt = make_pkt (ACK, chksum) udt_send( sndpkt) rdt_rcv (rcvpkt) && not corrupt (rcvpkt) && has_seq1(rcvpkt) rdt_rcv (rcvpkt) && corrupt (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 Reliable Data Transfer #18

rdt2.1: discussion Sender: r seq # added to pkt r two seq. #’s (0,1) will suffice. Why? r must check if received ACK/NAK corrupted r twice as many states m state must “remember” whether “current” pkt has 0 or 1 seq. # Receiver: r must check if received packet is duplicate m state indicates whether 0 or 1 is the expected packet sequence # r 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

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

Reliable Data Transfer#21 rdt3.0: channels with errors and loss New assumption: underlying channel can also lose packets (data or ACKs) m checksum, seq. #, ACKs, retransmissions will be of help, but not enough Q: how to deal with loss? Proposal: m sender waits until certain data or ACK lost, then retransmits m feasible? Approach: sender waits “reasonable” amount of time for ACK r retransmits if no ACK received in this time r if pkt (or ACK) just delayed (not lost): m retransmission will be duplicate, but use of seq. #’s already handles this m receiver must specify seq # of pkt being ACKed r requires countdown timer on the sender side

Reliable Data Transfer#22 rdt 3.0 assumptions on uc r FIFO: m Data packets and Ack packets are delivered in order. r Errors and Loss: m Data and ACK packets might get corrupt or lost r No duplication: but can handle it! r Liveness: m If continuously sending packets, eventually, an uncorrupted packet received.

Reliable Data Transfer#23 rdt3.0 sender

Reliable Data Transfer#24 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

Reliable Data Transfer#25 rdt3.0 in action

Reliable Data Transfer#26 rdt3.0 in action

Reliable Data Transfer#27 Performance of rdt3.0 r rdt3.0 works, but performance stinks r 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 = m 1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link m transport protocol limits use of physical resources!

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

Pipelined protocols Pipelining: sender allows multiple, “in-flight”, yet-to- be-acknowledged pkts m range of sequence numbers must be increased m buffering at sender and/or receiver r Two generic forms of pipelined protocols: go-Back-N, selective repeat Reliable Data Transfer#29

Pipelining: increased utilization first packet bit transmitted, t = 0 senderreceiver RTT last bit transmitted, t = L / R first packet bit arrives last bit of packet arrives, send ACK ACK arrives, send next packet, t = RTT + L / R last bit of 2 nd packet arrives, send ACK last bit of 3 rd packet arrives, send ACK 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: r unbounded seq. num, starting at 0 r window size = N : up to N consecutive unack’ed pkts allowed Initialization r Receiver knows when to expect packet 0 r ACK(n): ACKs all pkts up to, including seq # n - “cumulative ACK” m may receive duplicate ACKs (see receiver) r timer points to the packet at base r 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 receiver simple: r ACK-only: always send ACK for correctly-received pkt with highest in-order seq # m may generate duplicate ACKs  need only remember expectedseqnum r out-of-order pkt: m discard (don’t buffer) -> no receiver buffering! m ACK pkt with highest in-order seq # expectedseqnum = expectedseqnum+1 = highest received seq.num Reliable Data Transfer#34

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

GBN: Correctness r Claim I (safety): m The receiver delivers the data in the correct order m Proof: unbounded seq. num. QED r Claim I (seqnum): m In the receiver: Value of expectedseqnum only increases (in broad sense) m 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 r Let: m base=k; expectedseqnum=m; nextseqnum=n; r Observation: k ≤ m ≤ n r Claim (Liveness): m If k<m then eventually base ≥ m 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. 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. Corollary: Sufficient to use N+1 seq. num. Data i<k-N Not in send window with k Ack i<k Seq num only increases Reliable Data Transfer#38

Selective Repeat Reliable Data Transfer#39

Selective Repeat r receiver individually acknowledges all correctly received pkts m buffers pkts, as needed, for eventual in-order delivery to upper layer r sender only resends pkts for which ACK not received m individual sender timer for each unACKed pkt r sender window m N consecutive seq #’s m again limits seq #s of sent, unACKed pkts Reliable Data Transfer#40

Selective repeat: sender, receiver windows Reliable Data Transfer#41

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

Selective repeat in action Reliable Data Transfer#43

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

Selective repeat: dilemma Example: r seq #’s: 0, 1, 2, 3 r window size=3 r receiver sees no difference in two scenarios! r Incorrectly m Passes duplicate data as new in (a) or m Discards in (b) Q: what relationship between seq # size and window size? Reliable Data Transfer#45

Choosing the window size r Small window size: m idle link (under-utilization). r Large window size: m Buffer space m Delay after loss r Ideal window size (assuming very low loss) m RTT =Round trip time m C = link capacity m window size = RTT * C r What happens with no loss? Reliable Data Transfer#46