Reliable Delivery

1. Reliable Delivery Through Numbering and Retransmission

2. hello! hello! my dog’s name is spot spot Reliable Transmission

3. hello! spot my is dog’s my name name is spot. Reliable Transmission

4. Channel misbehavior • Message corruption • Contents of a message are altered • Detected via CRC’s (or other scheme) • Packet is dropped (i.e. it is now a “loss”) • Message loss • A sent message is never delivered • Message reorder • Two messages sent arrive in different order at receiver. • Message duplication (rare) • More than one copy of the same message is received.

5. Reliable Transmission • Suppose error detection (CRC, parity) identifies valid and invalid packets • Can we make the channel appear reliable? • Insure packet delivery • Maintain packet order • Also, can we provide reliability at full link capacity? • Tools: • Acknowledgements (notify that packet is received) • Timers (detect when packet is lost) • Sequence numbers

6. Application Application Transport Transport Network Network Data Link Data Link Physical Physical Which layers might use reliable transmission? Channel • Data link layer: make sure the message gets to the next node (channel will lose but not reorder msgs) • Transport layer: make sure the message gets to the ultimate destination (channel will lose and reorder msgs) Network Channel Channel Data Link Physical

7. Messages • Using framing, we can distinguish the beginning and end of each message. • Header Body Trailer • Header: • Typically of constant size, and contains multiple fields. • Includes source address, destination address, message type, number of bytes in data, sequence numbers, etc. • Body: • This carries the “data” of the message • Usually the data is just a message from a higher layer • Trailer: • Usually just a CRC

8. Frame ACK Typical message types Sender Receiver • Frame: • Carries data from the higher layer (usually) • ACK: • Indicates if a frame is received (or not received) • Types: (a) individual: acknowledges a single frame (b) cumulative: acknowledges multiple frames (c) negative: says a frame was not received

9. Channel “good behavior” • Messages are assumed to have an upper limit on their lifetime in a channel (call it “lifetime”) • In point-to-point links, it is the propagation delay of the channel PLUS the processing delay at the next node • Losses are detected using timeouts (TO) • The operation of a TO is as follows: • A sender keeps track of the time it sent each frame. • If within 2*lifetime seconds no ACK is received, the message is assumed lost • The message is then retransmitted.

10. Frame Timeout Frame Timeout ACK Timeout example Sender Receiver Time

11. Reliable Transmission Outline • Automatic Repeat reQuest (ARQ) algorithms: • A family of algorithms that provide reliability through retransmission • ARQ algorithms (simple to complex) • stop-and-wait (alternating-bit protocol) • concurrent logical channels • sliding window • go-back-n • selective repeat • Alternative: forward error correction (FEC) • No retransmission (send redundant information)

12. Stop-and-Wait • Basic idea • Send the frame • Wait for an ACK or TO • If TO, go to 1 • If ACK, get new frame, go to 1

13. Frame Timeout ACK Stop-and-Wait: Success Sender Receiver Time

14. Frame Timeout Frame Timeout ACK Stop-and-Wait: Lost Frame Sender Receiver Time

15. Frame Timeout ACK Frame Timeout ACK Stop-and-Wait: Lost ACK Sender Receiver Time

16. Stop-and-Wait • Goal • Guaranteed, at-most-once delivery • Assumptions • Channel does not duplicate messages • Timeouts are accurate (i.e. messages have an upper bound on their lifetimes in the channel) • Can message reorder occur under the above assumptions? • Requirements • 1-bit sequence number

17. Frame Frame Timeout Timeout ACK Frame Frame Timeout Timeout ACK ACK ACK Why sequence number? • How can the receiver distinguish between these two scenarios? Sender Receiver Sender Receiver Time

18. Frame(0) Frame(0) Frame(1) Timeout Timeout ACK(1) Frame(0) Frame(1) Frame(1) Frame(0) Timeout Timeout Timeout Timeout ACK(0) ACK(1) ACK(0) ACK(1) ACK(0) Sender Receiver

19. process sender variables body : data from higher layer sb: bit of last frame sent ab: bit of last acknowledgment begin event: sb = ab resp: body := message from higher layer sb := (sb+1) mod 2 send frame(sb, body) to receiver /* place a copy of frame(sb, body) in the channel */ /* further modification of variables sb and body do not affect the messages in the channel */ event: receive ack(ab) from receiver resp: null /* if ack(0) then ab is set to 0, etc. */ event: timeout for last message sent resp: if sb ≠ ab then send frame(sb, body) to receiver fi end

20. process receiver variables body : data to be delivered to higher layer nb: bit of next frame to deliver to app b: bit in frame just received begin event: receive frame(b, body) from sender resp: send ack(b) to sender if b = nb then /* = is logical equal, not asignment */ deliver body to higher layer; nb := (nb + 1) mod fi end

21. Process notation (mine) • Processes communicate by sending messages to each other • A set of actions ((event, response) pairs) • Each action is of one of three types • Local • Receive • Timeout • The order in which I write the actions is irrelevant • The order in which they are executed is not pre-determined • Actions are executed, one at a time, if their event is true • This lack of order actually gives us flexibility in implementation • Executing an action is executing the statements of its response

22. Channel Constraints, and protocol states • Note that we have always a single message in each channel (frame one way and ack the other way) (Actually, both channels combined have a single message) • A state of the protocol is choosing one particular value for each variable, and choosing the contents of the channel • E.g., one state could besender.sb = 0, sender.ab = 1, channel.sender.receiver = <frame(0)>, channel.receiver.sender = empty, receiver.nb = 0.

23. Protocol states (continued) In the statesender.sb = 0, sender.ab = 1, channel.sender.receiver = <frame(0)>, channel.receiver.sender = empty, receiver.nb = 0,which actions are enabled? Assuming the protocol begins in a state,sender.sb = 0, sender.ab = 0, channel.sender.receiver = empty, channel.receiver.sender = empty, receiver.nb = 1.what are the total number of states reachable by the protocol? Can you give a state that is not reachable?

24. Accurate Timeouts (or not) • What if our timeout mechanism is not accurate? (i.e., retransmit unnecessarily) • If the channel does not reorder messages, then it works • If the channel does reorder messages, then it does not! • Note that reorder is irrelevant if the timeout is accurate. • In this case we are like before, at most one message in both channels

25. 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 receiver sender 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 receiver sender 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 No reorder …

26. 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 receiver receiver sender sender 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 No reorder

27. 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 receiver sender 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 receiver sender 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 Reorder Reorder occurs from sender to receiver

28. 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 1 1 1 1 receiver sender 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 0 receiver sender 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 Reorder What happens when the next 0 is received by the receiver?

29. (answer: it believes it is new! When we know it is not)

30. Stop-and-Wait • Problem • Only allows one outstanding frame • Does not keep the pipe full • Example • 1.5 Mbps link, 45ms RTT • One frame (1KB) per RTT • Usage • bits per frame / time per frame = 1024x8/0.045 • = 182 Kbps • = 1/8 capacity! • Note: Delay X BW = 67.5 Kb  8KB • The network can “store” 8KB in flight, we only have 1 KB in flight, hence,

31. Concurrent Logical Channels • Idea • Multiplex multiple logical channels over a single channel • Logical channel number is in the header • Use stop-and-wait for each logical channel • Result • Each logical channel is limited to stop-and-wait bandwidth • Aggregate bandwidth uses full physical channel (if enough logical channels), by having multiple outstanding messages at a time. • Supports multiple communicating processes • Can use more than one channel per process

32. receiver sender There is only one *real* channel The difference between logical channels is just in the header of the frames

33. Notation param i: 0 .. 2 event: . . . i . . . resp: . . . i . . . is equivalent to: event: . . . 0 . . . resp: . . . 0 . . . event: . . . 1 . .. resp: . . . 1 . . . event: . . . 2 . . . resp: . . . 2 . . .

34. process sender const N : number of logical channels var body : array[0 .. N-1] of whatever sb: array[0 .. N-1] of 0 .. 1 ab: array[0 .. N-1] of 0 .. 1 b: 0 .. 1 {bit in ack} n: 0 .. N-1 {channel number in ack} param i: 0 .. N-1

35. begin • event: sb[i] = ab[i] • resp: body[i] := message from higher layer • sb[i] := (sb[i] + 1) mod 2 • send frame(i, sb[i], body[i]) to receiver • event:receive ack(n, b) from receiver • resp: ab[n] := b • event:timeout for message sent in channel i • resp: if sb[i] ≠ ab[i] then • send frame(i, sb[i], body[i]) to receiver • fi • end

36. process receiver const N: number of channels variables nb: array [0 .. N-1] of 0..1 {next bit expected} body: data to be delivered to higher layer b: 0..1 {bit received in frame} n: 0 .. N-1 {channel number of frame} begin event:receive frame(n, b, body) from sender resp: send ack(n, b) to sender; if b = nb[n] then deliver body to higher layer nb[n] := (nb[n] + 1) mod 2 fi

37. Nondeterministic Execution • When multiple actions are enabled, which one do you execute next? • If multiple actions are enabled within the same process, I leave it open to the implementation to choose which one • If actions from different processes are enabled • You can’t tell which action will execute next (depends on the relative speed of the processes) • We model this with nondeterminism • Arbitrarily, one action will be chosen for execution, which then yields a new state. • Your protocol should work correctly regardless of which action is chosen.

38. Channel Reorder in Concurrent Logical Channels Does the protocol work if channels can reorder messages?

39. Concurrent Logical Channels • Problem • Use of a single channel per process may waste BW • Use of multiple channel per process does not maintain packet ordering across channels!

40. ARQ: Where are We? • Recall goals for reliable transmission • Make channel appear reliable • Maintain packet order (we usually want this) • Impose low overhead/allow full use of link • Stop-and-Wait • Provides reliable in-order delivery • Sacrifices performance • Concurrent Logical Channels • Provides reliable delivery at full link bandwidth • Sacrifices packet ordering • Sliding Window Protocol • Achieves all three!