2. 3: Transport Layer 3a-1 8: Principles of Reliable Data Transfer Last Modified: 10/15/2015 7:04:07 PM Slides adapted from: J.F Kurose and K.W. Ross, 1996-2010

3. 3: Transport Layer 3a-2 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

4. 3: Transport Layer 3a-3 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!

5. 3: Transport Layer 3a-4 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?

6. 3: Transport Layer 3a-5 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?

7. 3: Transport Layer 3a-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

8. 3: Transport Layer 3a-7 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 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

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

10. Transport Layer 3-9 Rdt2.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 m negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors m sender retransmits pkt on receipt of NAK  new mechanisms in rdt2.0 (beyond rdt1.0 ): m error detection m receiver feedback: control msgs (ACK,NAK) rcvr->sender How do humans recover from “errors” during conversation?

11. 3: Transport Layer 3a-10 Rdt2.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 acknowledgements (ACKs): receiver explicitly tells sender that pkt received OK m negative acknowledgements (NAKs): receiver explicitly tells sender that pkt had errors m sender retransmits pkt on receipt of NAK m human scenarios using ACKs, NAKs?

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

13. 3: Transport Layer 3a-12 rdt2.0: FSM specification sender FSMreceiver FSM

14. 3: Transport Layer 3a-13 rdt2.0: in action (no errors) sender FSMreceiver FSM

15. 3: Transport Layer 3a-14 rdt2.0: in action (error scenario) sender FSMreceiver FSM

16. 3: Transport Layer 3a-15 rdt2.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)

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

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

19. 3: Transport Layer 3a-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 expected pkt seq # m 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

20. 3: Transport Layer 3a-19 rdt2.2: a NAK-free protocol r Less intuitive but getting us closer to TCP r same functionality as rdt2.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

21. rdt2.2: sender, receiver fragments

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

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

24. 3: Transport Layer 3a-23 rdt3.0 in action

25. 3: Transport Layer 3a-24 rdt3.0 in action

26. 3: Transport Layer 3a-25 Stop and Wait r Rdt3.0 also called Stop and Wait  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