Reliable Data Transfer

1. Reliable Data Transfer Reliable Data Transfer

2. 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 Transport Layer Reliable Data Transfer

3. 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 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 Transport services and protocols Similar issues at data link layer Reliable Data Transfer

4. TCP : reliable, in-order deliveryConnection-Oriented connection setup 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 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 Internet transport-layer protocols Reliable Data Transfer

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

6. rdt_send():called from above, (e.g., by app.). Passed data to deliver to receiver upper layer deliver_data():called by rdt to deliver data to upper udt_send():called by rdt, to transfer packet over unreliable channel to receiver rdt_rcv():called when packet arrives on rcv-side of channel Reliable data transfer: getting started send side receive side Reliable Data Transfer

7. 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

8. 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

9. 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 event state 1 state 2 actions Reliable data transfer: protocol model event causing state transition actions taken on state transition state: when in this “state”, next state uniquely determined by next event Reliable Data Transfer

10. 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 Rdt1.0: reliable transfer over reliable channel init init rdt_send( data) rdt_rcv( packet) Wait for call from below Wait for call from above extract (packet, data) deliver_data (data) packet = make_pkt (data) udt_send (packet) sender receiver Reliable Data Transfer

11. 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 Rdt2.0: channel with bit errors Reliable Data Transfer

12. 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

13. rdt2.0: FSM specification receiver sender rdt_send (data) rdt_rcv (rcvpkt) && corrupt (rcvpkt) sndpkt = make_pkt (data, checksum) udt_send (sndpkt) init udt_send (NAK) rdt_rcv (rcvpkt) && isNAK (rcvpkt) init Wait for call from above Wait for ACK or NAK Wait for call from below udt_send (sndpkt) rdt_rcv (rcvpkt) && isACK (rcvpkt) L rdt_rcv (rcvpkt) && notcorrupt (rcvpkt) extract (rcvpkt, data) deliver_data (data) udt_send (ACK) Notation: Λ = No Action && = AND || = OR New items written inred Reliable Data Transfer

14. rdt2.0: in action (no errors) L sender FSM receiver FSM Reliable Data Transfer

15. rdt2.0: in action (error scenario) L sender FSM receiver FSM Reliable Data Transfer

16. 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 asequence 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 rdt2.0 has a fatal flaw! Reliable Data Transfer

17. Wait for ACK or NAK 0 Wait for call 1from above Wait for ACK or NAK 1 rdt2.1 handles garbled ACK/NAKs : Sender rdt_send (data) sndpkt = make_pkt (0, data, checksum) udt_send (sndpkt) init rdt_rcv (rcvpkt) && ( corrupt (rcvpkt) || isNAK (rcvpkt) ) Wait for call 0 from above udt_send (sndpkt) rdt_rcv (rcvpkt) && notcorrupt (rcvpkt) && isACK (rcvpkt) rdt_rcv (rcvpkt) && notcorrupt (rcvpkt) && isACK (rcvpkt) L L rdt_rcv (rcvpkt) && ( corrupt (rcvpkt) || isNAK (rcvpkt) ) rdt_send (data) sndpkt = make_pkt (1, data, checksum) udt_send (sndpkt) udt_send (sndpkt) Reliable Data Transfer

18. Wait for 0 from below Wait for 1 from below rdt2.1 handles garbled ACK/NAKs: Receiver rdt_rcv (rcvpkt) && notcorrupt (rcvpkt) && has_seq0 (rcvpkt) extract (rcvpkt,data) deliver_data (data) sndpkt = make_pkt (ACK, chksum) udt_send (sndpkt) init rdt_rcv (rcvpkt) && corrupt (rcvpkt) rdt_rcv (rcvpkt) && corrupt (rcvpkt) sndpkt = make_pkt (NAK, chksum) udt_send (sndpkt) sndpkt = make_pkt( NAK, chksum) udt_send (sndpkt) rdt_rcv (rcvpkt) && not corrupt (rcvpkt) && has_seq1(rcvpkt) rdt_rcv (rcvpkt) && not corrupt (rcvpkt) && has_seq0 (rcvpkt) sndpkt = make_pkt (ACK, chksum) udt_send (sndpkt) sndpkt = make_pkt (ACK, chksum) 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

19. 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 rdt2.1: discussion 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

20. 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 rdt2.2: a NACK-free protocol sender FSM ! Reliable Data Transfer

21. 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 timeron the sender side rdt3.0: channels with errors and loss Reliable Data Transfer

22. 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

23. rdt3.0 sender Reliable Data Transfer

24. rdt 3.0 receiver rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) Extract(rcvpkt,data) deliver_data(data) udt_send(ACK[0]) rdt_rcv(rcvpkt) && corrupt(rcvpkt) rdt_rcv(rcvpkt) && corrupt(rcvpkt) udt_send(ACK[0]) udt_send(ACK[1]) Wait for 1 Wait for 0 rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq0(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) rdt_rcv(rcvpkt) && notcorrupt(rcvpkt) && has_seq1(rcvpkt) udt_send(ACK[0]) udt_send(ACK[1]) Extract(rcvpkt,data) deliver_data(data) udt_send(ACK[1]) Reliable Data Transfer

25. rdt3.0 in action Reliable Data Transfer

26. rdt3.0 in action Reliable Data Transfer

27. rdt3.0 works, but performance stinks example: 1 Gbps link, 15 ms e-e prop. delay, 1KB packet: fraction of time sender busy sending = = 0.00027 Utilization = U = 8kb/pkt T = 8 microsec = 8 microsec transmit 10**9 b/sec 30.016 msec Performance of rdt3.0 • 1KB pkt every 30 msec -> 33kB/sec thruput over 1 Gbps link • transport protocol limits use of physical resources! Reliable Data Transfer

28. 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 Reliable Data Transfer

29. 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 Pipelined protocols Reliable Data Transfer

30. Pipelining: increased utilization sender receiver first packet bit transmitted, t = 0 last bit transmitted, t = L / R first packet bit arrives RTT 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 utilizationby a factor of 3 (!) 3 = “window size” here Reliable Data Transfer

31. Go Back N (GBN) Reliable Data Transfer

32. 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 Go-Back-N • 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

33. GBN: sender extended FSM /*for the packet at the new base*/ Reliable Data Transfer

34. 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 # GBN: receiver extended FSM expectedseqnum = expectedseqnum+1 = highest received seq.num Reliable Data Transfer

35. GBN inaction Start timer 0 window size = 4 Stop timer 0, start timer 1 Stop timer 1, start timer 2 Reliable Data Transfer

36. 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

37. 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

38. Ack i<k Seq num only increases Ack i<k Ack k impossible impossible Data i<k-N Data k Data i<k-N Not in send window with k 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. Clearing a FIFO channel: Corollary: Sufficient to use N+1 seq. num. Reliable Data Transfer

39. Selective Repeat Reliable Data Transfer

40. 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 Reliable Data Transfer

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

42. 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 # receiver sender Selective repeat pkt n in [rcvbase, rcvbase+N-1] • send ACK(n) • out-of-order: buffer • in-order: deliver (also 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

43. Selective repeat in action Reliable Data Transfer

44. 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

45. 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? Selective repeat: dilemma Reliable Data Transfer

46. 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