Chapter 6 Reliable Data Transfer

1. Chapter 6 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: transport layer: data transfer between end system processes relies on, enhances, network layer services network layer: data transfer between end systems datalink layer: data transfer between connected NICs issues similar to those of the transport layer (exc. cong.ctrl) 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 Reliable Data Transfer

4. 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 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. 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: Setting 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: dramatis personæ 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 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 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 deliver_data (data_outj), j L received • For every i  L: data_ini = data_outi • Liveness (needs assumptions): • For every i there exists j 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 machine (FSM) notation to specify sender, receiver actions; as follows: event event state 1 state 2 actions 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, duplication or misordering of packets separate FSMs for sender, receiver: sender sends data into underlying channel receiver reads data from underlying channel & delivers it 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/ duplicated/ misordered 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 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. 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 in red 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 Qn: Can you find a problem rdt 2.0 ? Reliable Data Transfer

16. 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 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  rdt 2.1 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 Why is this sufficient? 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 explicitlyinclude 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 init 0 Note: L 1 Note: receiverFSM identical with 3.0 (below) 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 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 timeron the sender side rdt3.0: channels with errors and loss Reliable Data Transfer

22. rdt 3.0 assumptions on uc • FIFO: • Data packets & Ack packets are delivered in order. • Errors and Loss: • Data and ACK packets might get corrupt or lost • No duplication in uc, but RDT can cause duplication • Note: rdt hides duplications and other errors from user layer • Liveness: • If continuously sending packets, eventually, an uncorrupted packet received. Reliable Data Transfer

23. rdt3.0 : sender init 0 1 Reliable Data Transfer

24. Wait for 0 from below Wait for 1 from below rdt3.0 : Receiver rdt_rcv (rcvpkt) && notcorrupt (rcvpkt) && has_seq0 (rcvpkt) extract (rcvpkt,data) deliver_data (data) sndpkt = make_pkt (ACK0, chksum) udt_send (sndpkt) init rdt_rcv (rcvpkt) && corrupt (rcvpkt) rdt_rcv (rcvpkt) && corrupt (rcvpkt) sndpkt = make_pkt (ACK1, chksum) udt_send (sndpkt) sndpkt = make_pkt( ACK0, 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 (ACK1, chksum) udt_send (sndpkt) sndpkt = make_pkt (ACK0, chksum) udt_send( sndpkt) rdt_rcv (rcvpkt) && notcorrupt (rcvpkt) && has_seq1(rcvpkt) extract (rcvpkt,data) deliver_data (data) sndpkt = make_pkt (ACK1, chksum) udt_send (sndpkt) Reliable Data Transfer

25. rdt3.0 in action Reliable Data Transfer

26. rdt3.0 in action rcv ACK1/ignore* rcv ACK0 send pkt1 * duplicate ACK 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 Qn: Can we get 100% utilization? 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” • sender may receive duplicate ACKs (see receiver) • timer refers to the packet at base • timeout(n): retransmit pkt n and all higher seq # pkts in buffer Reliable Data Transfer

33. GBN: extended FSM - sender /*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 data pkt: discard (don’t buffer) -> no receiver buffering! ACK pkt with highest in-order seq # GBN: extended FSM - receiver 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. Selective Repeat Reliable Data Transfer

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

38. Selective repeat: sender, receiver windows Sender Receiver Reliable Data Transfer

39. 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 є[rcvbase, rcvbase+N-1] • send ACK(n) • out-of-order: buffer • in-order: deliver (deliver all buffered, in-order pkts in buffer), advance window start to next not-yet-received pkt pkt n є[rcvbase-N,rcvbase-1] • send ACK(n) otherwise: • ignore Reliable Data Transfer

40. Selective repeat in action Reliable Data Transfer

41. Numbering range & Window size • So far packet numbers were unlimited • In practice we allow integers in [1, K] • Question is: Given window size N, what is the minimal value of K that will work? • Answer is: • For GBN we need K to be at least N+1 • For SR we need K to be at least 2N • The justification for this is outlined in the next slides Reliable Data Transfer

42. Optional: Correctness Discussion Reliable Data Transfer

43. GBN: Correctness • As usual we assume channel is FIFO • Claim I (safety): • The receiver delivers the data in the correct order • Proof: unbounded seq. num. QED Qn: Why? • 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

44. GBN: correctness - liveness • Let: base=k; expectedseqnum=m; nextseqnum=n • Observation: k ≤ m ≤ n • k<m: m-k pkts received at destination; their acks not yet received by the sender • m<n: n-m pkts sent; not yet received at dest. • 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

45. Ack i<k Ack k impossible impossible Data i<k-N Data 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.(ass. FIFO) Ack i<k impossible Seq num only increases Clearing a FIFO channel: Data i<k-N impossible Not in same send window with k Corollary: Sufficient to use N+1 seq. num. Reason: all we need is prevent taking an old pkt as a new one Reliable Data Transfer

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

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