8 Principles of Reliable Data Transfer Last Modified

8: Principles of Reliable Data Transfer Last Modified: 12/1/2020 1: 22: 31 AM Slides adapted from: J. F Kurose and K. W. Ross, 1996 -2010 3: Transport Layer 3 a-1

Roadmap r UDP is a very thin layer over IP m multiplexing /demultiplexing m error detection r TCP does these things also and then adds some other significant features r TCP is quite a bit more complicated and subtle r We are not going to jump right into TCP r Start gently thinking about principles of reliable message transfer in general 3: Transport Layer 3 a-2

The Problem r Problem: send big message (broken into pieces) over unreliable channel such that it arrives on other side in its entirety and in the right order r No out of band communication! All communication sent along with the pieces of the message r Receiver allowed to send information back but only over the same unreliable channel! 3: Transport Layer 3 a-3

Intuition: Faxing a document With Flaky Machine r Can’t talk to person on the other side any other way r Number the pages – so sender can put back together r Let receiver send you a fax back saying what pages they have and what they still need (include your fax number on the document!) r What if the receiver sends their responses with a flaky fax machine too? r What if it is a really big document? No point in overwhelming the receiver. Receiver might like to be able to tell you send first 10 pages then 10 more… r How does receiver know when they have it all? Special last page? Cover sheet that said how many to expect? 3: Transport Layer 3 a-4

Principles of Reliable data transfer r Solving this problem is one on top-10 list of most important networking topics! m important in application, transport, link layers r Characteristics of unreliable channel will determine complexity of reliable data transfer protocol– what is worst underlying channel can do? m Drop packets/pages? m Corrupt packet/pages (even special ones like the cover sheet or the receiver’s answer? ) m Reorder packets/pages? 3: Transport Layer 3 a-5

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

Reliable data transfer: getting started 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: when in this “state” next state uniquely determined by next event state 1 event causing state transition actions taken on state transition event actions state 2 3: Transport Layer 3 a-7

Rdt 1. 0: reliable transfer over a reliable channel r underlying channel perfectly reliable (so this should be easy ) m m no bit errors no loss of packets r separate FSMs for sender, receiver: m sender sends data into underlying channel m receiver read data from underlying channel 3: Transport Layer 3 a-8

Rdt 2. 0: channel with bit errors r underlying channel may flip bits in packet m checksum to detect bit errors r the question: how to recover from errors: m acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK How do humans recover from “errors” m negative acknowledgements (NAKs): receiver explicitly tells sender during that pkt conversation? had errors m sender retransmits pkt on receipt of NAK r new mechanisms in rdt 2. 0 (beyond rdt 1. 0): m m error detection receiver feedback: control msgs (ACK, NAK) rcvr->sender Transport Layer 3 -9

Rdt 2. 0: channel with bit errors r underlying channel may flip bits in packet (can’t drop or reorder packets) m recall: UDP checksum to detect bit errors r Once can have problems, the receiver must give the sender feedback (either that or the sender would just have to keep sending copy after copy forever to be sure) r After receiving a packet, the receiver could say one of two things: m m acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors sender retransmits pkt on receipt of NAK human scenarios using ACKs, NAKs? 3: Transport Layer 3 a-10

Rdt 2. 0: channel with bit errors r new mechanisms in rdt 2. 0 (beyond rdt 1. 0): m m m receiver feedback: control msgs (ACK, NAK) rcvr->sender (let receiver fax you back info? ) Possible retransmission – detection of duplicates (number fax pages? ) error detection (checksums? Cover sheet summary? ) 3: Transport Layer 3 a-11

rdt 2. 0: FSM specification sender FSM receiver FSM 3: Transport Layer 3 a-12

Question r Can you explain how to implement the functions corrupt(packet) and notcorrupt (packet)? r T/F: Based on what UDP and TCP do, you can say for sure there is a corruption/problem but you can’t say for sure there is not? 3: Transport Layer 3 a-13

rdt 2. 0: in action (no errors) sender FSM receiver FSM 3: Transport Layer 3 a-14

rdt 2. 0: in action (error scenario) sender FSM receiver FSM 3: Transport Layer 3 a-15

rdt 2. 0 has a fatal flaw! What happens if ACK/NAK corrupted? r sender doesn’t know what happened at receiver! r FSM implied could tell if it was and ACK or a NACK r What if is a FLACK? What to do? r Assume it was an ACK and transmit next? What if it was a NACK? Missing data r Assume it was a NACK and retransmit; What if it was an ACK? Duplicate data Handling duplicates: r To detect duplicate, sender adds sequence number to each pkt r sender retransmits current pkt if ACK/NAK garbled r If receiver has pkt with that number already it will discards (I. e. not deliver up duplicate pkt) 3: Transport Layer 3 a-16

rdt 2. 1: sender, handles garbled ACK/NAKs New: compute_chksum corrupt() 3: Transport Layer 3 a-17

rdt 2. 1: receiver, handles garbled ACK/NAKs If not corrupt, always send ACK, but only Deliver_data first time 3: Transport Layer 3 a-18

rdt 2. 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 m state indicates whether 0 or 1 is expected pkt seq # Note: This protocol can also handle if the channel can duplicate packets r note: when can sender and receiver safely exit? receiver can not know if its last ACK/NAK received OK at sender m Missing connection termination procedure 3: Transport Layer 3 a-19

rdt 2. 2: a NAK-free protocol r Less intuitive but getting us closer to TCP r same functionality as rdt 2. 1, using NAKs only r instead of NAK, receiver sends ACK for last pkt received OK (or for other number on the first receive) m receiver must explicitly include seq # of pkt being ACKed r duplicate (or unexpected) ACK at sender results in same action as NAK: retransmit current pkt r TCP really ACKS the next thing it wants 3: Transport Layer 3 a-20

rdt 2. 2: sender, receiver fragments

rdt 3. 0: channels with errors (and duplicates) and loss New assumption: underlying channel can also lose packets (data or ACKs) m m How to deal with loss? Retransmission plus seq # to detect duplicates but not enough Q: how to detect loss? 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 3: Transport Layer 3 a-22

rdt 3. 0 sender Start_timer Timeout events 3: Transport Layer 3 a-23

rdt 3. 0 in action 3: Transport Layer 3 a-24

rdt 3. 0 in action 3: Transport Layer 3 a-25

Stop and Wait r Rdt 3. 0 also called Stop and Wait m Sender sends one packet, then waits for receiver response r What is wrong with stop and wait? m Slow!! Must wait full round trip time between each send r Obvious Fix? m Instead send lots, then stop and wait m Call this a pipelined protocol because many packets in the pipeline at the same time 3: Transport Layer 3 a-26