1. CS/EE 145A Reliable Transmission over Unreliable Channel II Netlab.caltech.edu/course

2. Reliable Communication over Unreliable Channels Retransmission for Lost Packets: Loss Signals Retransmission for Lost Packets: Loss Signals Sliding-Window Algorithm Sliding-Window Algorithm Protocol State Machine Protocol State Machine Lab 3 Lab 3

3. Lab 3 How to split a file into packets? How to split a file into packets? How to detect errors (packet corruption, packet loss, duplication, reordering … )? How to detect errors (packet corruption, packet loss, duplication, reordering … )? How to recover from packets reordering? How to recover from packets reordering? How to recover from loss? How to recover from loss? How to use the bandwidth efficiently? How to use the bandwidth efficiently? How to share the bandwidth fairly? How to share the bandwidth fairly? …

4. Last class … TCP: Reliable Transmission Guarantee: The packets sent will be received with the same order. File System Stream P1, P2, … ???

5. This class! TCP: Reliable Transmission Guarantee: The packets sent will be received with the same order. IP: Unreliable Transmission Best Efforts: Packets can be dropped, can be reordered, can be duplicated, can be … Stream P1, P2, … ???

6. What ’ s the difference? Packets cannot arrive at the same time Packets cannot arrive at the same time The sender and receiver should be able to know the start of the flow and the end of the flow The sender and receiver should be able to know the start of the flow and the end of the flow The receiver has to let the sender know which packet is lost. The receiver has to let the sender know which packet is lost. Even worse … Even worse …

7. Loss Signals Form: Piggyback vs. Control Packet Form: Piggyback vs. Control Packet Signal: Acknowledgment vs. Negative Acknowledgement Signal: Acknowledgment vs. Negative Acknowledgement Amount of information: one packet vs. multiple packets Amount of information: one packet vs. multiple packets

8. Piggyback vs. Control Packet Piggyback Piggyback Each packet in the reverse traffic carries control information for the forward traffic. Each packet in the reverse traffic carries control information for the forward traffic. Good for two-way traffic. Good for two-way traffic. Robust Robust Less overhead Less overhead Control Packet Special packets carry control information Usually uses NACK Good for one way traffic May carry more information Less robust or More overhead?

9. ACK RTT time Source Destination 12W 1 12W data ACKs 12 12W

10. ACK (Loss Detection by Timeout) Time Out! RTT time Source Destination 12W 12W data ACKs 1 12W

11. ACK (False Loss) Time Out! RTT time Source Destination 12W 1 12W data ACKs 1 12W

12. NACK (Loss Detection) time Source Destination 12W data NACK:3 124 343 3412

13. NACK (NACK Loss) time Source Destination 12 data NACK:3 124 34 3412 W5 5 3 5

14. Stop & Wait RTT time Source Destination 12W 1 12W data ACKs 12 12W

15. Sliding Window ~ W packets per RTT ~ W packets per RTT RTT time Source Destination 12W12W12W data ACKs 12W w?

16. Loss Detection with Sliding Window Duplicate Acknowledgement indicates packet loss? Duplicate Acknowledgement indicates packet loss? RTT time Source Destination 12W 2W 12W ACK=1 12W ACK=w+1

17. How to start a flow? Three-way handshake for TCP Three-way handshake for TCP Simpler Handshake for one-way traffic: Simpler Handshake for one-way traffic: Add a flag field in packet header for starting signal Add a flag field in packet header for starting signal Anything to be negotiate in your protocol? Anything to be negotiate in your protocol?

18. How to end a flow? TCP style TCP style Simpler solution for one-way traffic? Simpler solution for one-way traffic? Add a flag field in packet header for ending signal? Add a flag field in packet header for ending signal? Which side should disconnect first? Why? Which side should disconnect first? Why? Does a perfect solution exist? Does a perfect solution exist?

19. How to design? The concept of protocol state and finite state machine (FSM) Have a clear idea of your design Have a clear idea of your design Follow the transition in state machine during implementation Follow the transition in state machine during implementation Test the implementation according to the transition graph Test the implementation according to the transition graph

20. State Transition Graph

21. Basic (FSM): Possible State Set Possible State Set Possible Input Set Possible Input Set Possible Output (Action) Set* Possible Output (Action) Set* State Transition Set: State Transition Set: {(origin_state[i], input[i], output[i], target_state[i])} Initial State Set Initial State Set

22. Concept of “ State Machine ” Flexible for Extensions: Variables Variables Timers Timers Informal conditions and actions Informal conditions and actions

23. Implement a State Machine Define protocol state: S Define protocol state: S Translate the transition graph into program: Translate the transition graph into program: If ((S== origin_state[i]) && (Input==input[i])) {Action=output[i]S=target_state[i]}

24. Test the implementation Design test case according to the transition graph: Design test case according to the transition graph: Is each transition covered by at least one test case? Is each transition covered by at least one test case? Is each action covered by at least one test case? Is each action covered by at least one test case?

25. States for TCP Connection

26. Lab 3

27. Lab 3 - Task Implement a reliable communication protocol over UDP: Implement a reliable communication protocol over UDP: Revise your packet format definition in Lab2 Revise your packet format definition in Lab2 Implement packet retransmission Implement packet retransmission

28. Lab 3 - Requirements  The implementation is based on UDP.  The implementation is able to send a file from one machine to the other.  The network in the middle is not reliable: The network may drop or duplicated or reorder some packets in the middle  Assumption: A single packet will not be contaminated. (Don ’ t worry about the error inside one packet)

29. Lab 3 - Details Two programs: “ sender ” and “ receiver ” Two programs: “ sender ” and “ receiver ” Sender should be able to read a file from the local disk, cut it into packets, and send it to the receiver. Sender should be able to read a file from the local disk, cut it into packets, and send it to the receiver. Sender can use a port to listen to the feedback from the receiver. Sender can use a port to listen to the feedback from the receiver. Receiver should be able to listen to a port, get the packets from the sender, and send feedback to the receiver, if necessary. Receiver should be able to listen to a port, get the packets from the sender, and send feedback to the receiver, if necessary. Assumption: Assumption: There is only one sender and one receiver. (All the packets to the sender is from the receiver, and vice versa.) There is only one sender and one receiver. (All the packets to the sender is from the receiver, and vice versa.) is a text file in the local disk is a text file in the local disk

30. Lab 3 – Details: Sender Format: “ sender ” Format: “ sender ” Port1: the port you are listening to the receiver ’ s feedback Port1: the port you are listening to the receiver ’ s feedback IP: the receiver ’ s IP IP: the receiver ’ s IP Port2: the receiver ’ s port Port2: the receiver ’ s port Filename: The file to be sent Filename: The file to be sent The sender should read from, send the content of the file to, and listen to port1 for feedback from the receiver. The sender should read from, send the content of the file to, and listen to port1 for feedback from the receiver.

31. Lab 3 – Details: Receiver Format: “ receiver ” Format: “ receiver ” Port1: the port you are listening to the sender ’ s data Port1: the port you are listening to the sender ’ s data IP: the sender ’ s IP IP: the sender ’ s IP Port2: the sender ’ s listening port Port2: the sender ’ s listening port Filename: The file to be saved Filename: The file to be saved The receiver should listen to for data, write the data to and send feedback to (sender) if necessary. The receiver should listen to for data, write the data to and send feedback to (sender) if necessary.

32. Lab 3 - Possible Problems How to design the packet format? How to design the packet format? What kind of feedback? (ACK/NACK? Control packet / piggyback?) What kind of feedback? (ACK/NACK? Control packet / piggyback?) How to detect loss? (Timeout? Duplicate ACK … ) How to detect loss? (Timeout? Duplicate ACK … ) How to maintain the window (If you use window scheme)? How to maintain the window (If you use window scheme)?

33. Lab 3 - Tips Re-Use the codes in Lab 1 and Lab 2 Re-Use the codes in Lab 1 and Lab 2 Packet format? Packet format? Packet type? (initial packet, ack packet, terminating packet … ) Packet type? (initial packet, ack packet, terminating packet … ) Packet length? Packet length? Packet sequence number? Packet sequence number? Data area … Data area … Window maintenance Window maintenance How to Test? How to Test?

34. Lab 3 Due: Nov 21 st (Friday) 23:59:59 Due: Nov 21 st (Friday) 23:59:59 Email: weixl@caltech.edu Email: weixl@caltech.eduweixl@caltech.edu Grading Grading TA hours: TA hours: Tue / Thu (20:00 – 22:00) JRG 170