CSEE 145A Reliable Transmission over Unreliable Channel II

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
• Sliding-Window Algorithm
• Protocol State Machine
• Lab 3

3
Lab 3

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

4
Last class
Stream
Stream
P1, P2,
???
5
This class!
Stream
Stream
P1, P2,
???
6
Whats the difference?

• 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 receiver has to let the sender know which
  packet is lost.
• Even worse

7
Loss Signals

• Form Piggyback vs. Control Packet
• Signal Acknowledgment vs. Negative
  Acknowledgement
• Amount of information one packet vs. multiple
  packets

8
Piggyback vs. Control Packet

• Piggyback
• Each packet in the reverse traffic carries
  control information for the forward traffic.
• Good for two-way traffic.
• Robust
• 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
1
2
W
Source
time
ACKs
Destination
1
1
2
time
10
ACK (Loss Detection by Timeout)

• Time Out!

1
2
W
Source
time
ACKs
Destination
1
time
11
ACK (False Loss)

• Time Out!

1
2
W
Source
time
ACKs
Destination
1
1
time
12
NACK (Loss Detection)
1
2
W
3
4
3
Source
time
NACK3
Destination
1
2
4
3
4
1
2
time
13
NACK (NACK Loss)
1
2

3
4
W
5
3
Source
time
NACK3
Destination
1
2
4
3
4
1
2
5
5
time
14
Stop Wait
1
2
W
Source
time
ACKs
Destination
1
1
2
time
15
Sliding Window
Source
time
w?
Destination
time

• W packets per RTT

16
Loss Detection with Sliding Window
Source
time
ACK1
ACKw1
Destination
2
W
time

• Duplicate Acknowledgement indicates packet loss?

17
How to start a flow?

• Three-way handshake for TCP
• Simpler Handshake for one-way traffic
• Add a flag field in packet header for starting
  signal
• Anything to be negotiate in your protocol?

18
How to end a flow?

• TCP style
• Simpler solution for one-way traffic?
• Add a flag field in packet header for ending
  signal?
• Which side should disconnect first? Why?
• 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
• Follow the transition in state machine during
  implementation
• Test the implementation according to the
  transition graph

20
State Transition Graph
21
State Transition Graph

• Basic (FSM)
• Possible State Set
• Possible Input Set
• Possible Output (Action) Set
• State Transition Set
• (origin_statei, inputi, outputi,
  target_statei)
• Initial State Set

22
Concept of State Machine

• Flexible for Extensions
• Variables
• Timers
• Informal conditions and actions

23
Implement a State Machine

• Define protocol state S
• Translate the transition graph into program
• If ((S origin_statei) (Inputinputi))
• Actionoutputi
• Starget_statei

24
Test the implementation

• Design test case according to the transition
  graph
• Is each transition 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
• Revise your packet format definition in Lab2
• 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. (Dont worry about the error inside
  one packet)

29
Lab 3 - Details

• 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 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.
• Assumption
• There is only one sender and one receiver. (All
  the packets to the sender is from the receiver,
  and vice versa.)
• ltFilenamegt is a text file in the local disk

30
Lab 3 Details Sender

• Format sender ltport1gt ltIPgt ltport2gt ltFilenamegt
• Port1 the port you are listening to the
  receivers feedback
• IP the receivers IP
• Port2 the receivers port
• Filename The file to be sent
• The sender should read from ltfilenamegt, send the
  content of the file to ltIPgt ltport2gt, and listen
  to port1 for feedback from the receiver.

31
Lab 3 Details Receiver

• Format receiver ltport1gt ltIPgt ltport2gt
  ltFilenamegt
• Port1 the port you are listening to the senders
  data
• IP the senders IP
• Port2 the senders listening port
• Filename The file to be saved
• The receiver should listen to ltport1gt for data,
  write the data to ltfilenamegt and send feedback to
  ltIPgt ltport2gt (sender) if necessary.

32
Lab 3 - Possible Problems

• How to design the packet format?
• What kind of feedback? (ACK/NACK? Control packet
  / piggyback?)
• How to detect loss? (Timeout? Duplicate ACK)
• How to maintain the window (If you use window
  scheme)?

33
Lab 3 - Tips

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

34
Lab 3

• Due Nov 21st (Friday) 235959
• Email weixl_at_caltech.edu
• Grading
• TA hours
• Tue / Thu (2000 2200) JRG 170