Chapter 2 Designing Reliable Protocols

1. Chapter 2Designing Reliable Protocols Professor Rick Han University of Colorado at Boulder rhan@cs.colorado.edu

2. Announcements • Moved to ECCR 265 • Larger classroom => graduate students on wait list may take the class • If not enough textbooks, send me email • First two lectures are online • TA has posted office hours and office on Web site • Homework #1 is on the Web site, due in 2 weeks • Programming assignment #1 available next class • Next, Chapter 2, reliable data-link protocols Prof. Rick Han, University of Colorado at Boulder

3. 1011000 Recap of Previous Lecture • Physical Layer • Encoding bits as analog waveforms, … • Ways to increase bit rate • Unreliability and propagation delay • Data Link Layer • Framing via byte/bit stuffing and length field in header • Error detection and correction Host A 1011000 Layer 2 Layer 1 Prof. Rick Han, University of Colorado at Boulder

4. Reliable Protocols • Why aren’t error detection and correction enough? • Receiver drops a packet when errors detected • Receiver can’t correct errors in some packets • Receiver never receives a packet • Solution: Retransmit lost or corrupt packets • Also called ARQ (Acknowledgement-Repeat-Request) Protocols • Useful for communicating non-delay-sensitive data, e.g. Web pages, files, email, even playback video • Can incur too much delay for interactive audio/video Prof. Rick Han, University of Colorado at Boulder

5. #5 1011000 Got #5 … Reliable Protocols (2) • How does sender detect when a packet needs to be retransmitted? • Analogy: Send a package by mail. How do I know it got there? Certified mail sends back a receipt. • In reliable protocols, Acknowledgements are sent by receiver back to sender confirming receipt of a packet • When an acknowledgment doesn’t arrive, then retransmit Sender Receiver Prof. Rick Han, University of Colorado at Boulder

6. #6 0100110 Got #6 … Reliable Protocols (3) • The sender knows that packet #5 was received correctly when it gets acknowledgement #5 • How does receiver know that sender got its acknowledgment? • Sender increments sequence number to #6 when acknowledgement #5 arrives. When receiver sees packet #6, it knows acknowledgement #5 made it Sender Receiver Prof. Rick Han, University of Colorado at Boulder

7. #5 1011000 Sender Receiver Got #5 … Reliable Protocols (4) • If the acknowledgement gets lost on the way back to sender, how does sender know it’s lost? • If an acknowledgement for a packet is not received by a timeout value, then sender assumes the packet is lost & retransmits it Prof. Rick Han, University of Colorado at Boulder

8. Reliable Protocols Thus Far • To detect when a packet needs to be retransmitted, reliable/ARQ protocols must use both: • Acknowledgements, and • Timeouts, • Sequence numbers: • Sender labels packets with them • For certain protocols, a receiver can infer correct reception of the acknowledgement for a packet with a lower sequence number Prof. Rick Han, University of Colorado at Boulder

9. Reliable Protocols: Other Points • Feedback loop allows receiver to send info about its state back to sender • Which acknowledgements have been received • Amount of room in my receive buffer (flow control) • Retransmission can work in conjunction with error detection/correction • Each packet has CRC/checksum. At receiver, if calculated checksum doesn’t match packet’s checksum, then discard packet. • Alternative policy? Receiver caches noisy packet for future error correction! • Retransmission can occur both at link layer and transport layer Prof. Rick Han, University of Colorado at Boulder

10. Got #6 Got <#7 … … ACK’s and NAK’s • Types of Acknowledgments • ACK’s – positive acknowledgements = “I’ve received these packets” • Cumulative • Selective • NAK’s – negative acknowledgements = “I have not received these packets” • ACK’s are more prevalent than NAK’s #6 0100110 Sender Receiver Prof. Rick Han, University of Colorado at Boulder

11. Timeouts • How would you choose the value of a timeout? • If timeout is too long, then waste bandwidth and send slowly. • “Too long” means timeout >> roundtrip time • Let’s approximate roundtrip time RTT = 2*(propagation delay), “>>” means “much greater than” • Example: if satellite link has prop. delay of 120 ms each way, then RTT = 240 ms. If timeout=1 min >> 240 ms, then send too slowly. • If timeout is too short, then retransmit unnecessarily • “Too short” means timeout < roundtrip time • Example: if timeout = 1 ms < RTT = 240 ms, then retransmit unnecessarily • Can have 2 or more copies of same packet in transit Prof. Rick Han, University of Colorado at Boulder

12. Designing Efficient Reliable Protocols • Already seen one way to improve efficiency: choose timeout wisely • Another way to improve efficiency: “keep the pipe full” with new data packets and necessary retransmissions • Stop-and-Wait • Go-Back-N • Selective Repeat (SRP) Prof. Rick Han, University of Colorado at Boulder

13. Receiver Sender Frame Timeout Period RTT Ack Next frame Ack time time Stop-and-Wait Protocol • After transmitting a packet/frame, the sender stops and waits for an ACK before transmitting the next frame • If a timeout occurs before receiving an ACK, the sender retransmits the frame • Link layer RTT = send time + process time at receiver + ACK send time • Here, timeout > RTT Prof. Rick Han, University of Colorado at Boulder

14. Stop-and-Wait Protocol (2) • If a timeout occurs before receiving an ACK, the sender retransmits the frame. Sender Receiver Frame Timeout Period Frame Ack time Prof. Rick Han, University of Colorado at Boulder

15. Stop-and-Wait Protocol (3) • If a timeout occurs before receiving an ACK, the sender retransmits the frame. Sender Receiver Frame Timeout Period Frame Ack time Prof. Rick Han, University of Colorado at Boulder

16. Stop-and-Wait Protocol (4) • Want timeout >= RTT to avoid spurious retransmissions of a frame/packet Sender Receiver Frame Unnecessary retransmission TO Ack RTT Frame Ack time Prof. Rick Han, University of Colorado at Boulder

17. Stop-and-Wait Protocol (5) • Label each packet and ACK with the proper sequence # to avoid confusion at receiver and sender Receiver Sender Frame #1 Timeout Period RTT ACK #1 Frame #2 ACK #2 time time Prof. Rick Han, University of Colorado at Boulder

18. Problem with Stop-and-Wait • Only one outstanding packet at a time => waste of link bandwidth • Example: 1.5 Mbps link with RTT 45 ms => a Delay*Bandwidthproduct = 67.5 Kb ≈ 8 KB. “pipe size” • If frame size = 1 KB, then use only 1/8 of bandwidth Sender Receiver Frame #1 RTT ACK #1 Frame #2 ACK #2 time time Prof. Rick Han, University of Colorado at Boulder

19. Frame #1 Frame #2 Frame #3 ACK #3 ACK #2 ACK #1 “Keep the Pipe Full” • During one RTT, send N packets • Example: 1.5 Mbps link with RTT 45 ms => a Delay*Bandwidthproduct = 67.5 Kb ≈ 8 KB. “pipe size” • If frame size = 1 KB, and N=3, then can have 3 outstanding packets, 3/8 of BW, and triple bandwidth utilization! Sender Receiver RTT time time Prof. Rick Han, University of Colorado at Boulder

20. Go-Back-N Sliding Window Protocol • Maintain a sliding window at both sender and receiver of unacknowledged packets • Send Window Size (SWS) • At sender: LAR (last ACK received), LFS (last frame sent) SWS … … LAR LFS • Sliding window: • When ACK arrives, slide LAR and LFS to right • LFS – LAR <= SWS (= delay*BW product?) • Retransmit entire window Prof. Rick Han, University of Colorado at Boulder

21. Go-Back-N Sliding Window Protocol (2) • At receiver: • Maintain a Receive Window Size (RWS) • At receiver: LAF (largest acceptable frame), LFR (last frame received) RWS … … LFR LAF • Sliding window: • When frame arrives, keep it if it’s within window • If frame #(LFR+1) arrives, then slide window to right (increment LFR and LAF) • Send back Cumulative ACK = LFR, LAF – LFR <= RWS Prof. Rick Han, University of Colorado at Boulder

22. Go-Back-N Sliding Window Protocol (3) • Example: RWS = 4, LFR = 5, LAF = 9. • Suppose at receiver frames #7 and #8 arrive, but frames #6 or #9 either arrive out of order or are lost. • When frame #7 arrives out of order, then send cumulative ACK with sequence #5 (same for frame #8) (alternative: delay ACKs until #6 arrives) • When frame #6 arrives, slide window (LFR’=8, LAF’=12), and send cumulative ACK #8. RWS=4 … … LFR=5 LAF=9 Prof. Rick Han, University of Colorado at Boulder LFR’=8 LAF’=12

23. SWS=6 Go-Back-N Sliding Window Protocol (4) • Meanwhile, back at the sender… • Example: suppose SWS=6, LAR=5, LFS=11 • Each time sender gets a cumulative ACK of #5, it retransmits frame #6 through frame #11 • When sender gets cumulative ACK #8, it slides window right (LAR’=8, LFS’=14), and transmits entire window (frame #9 thru #14) … … LAR=5 LFS=11 LAR’=8 LFS’=14 Prof. Rick Han, University of Colorado at Boulder

24. Problem with Go-Back-N • Cumulative ACK’s cause unnecessary retransmissions => inefficient • In our example, packets #7 and #8 are retransmitted even though they’ve already arrived at receiver • Solution: acknowledge each packet individually, or selectively, rather than cumulatively Prof. Rick Han, University of Colorado at Boulder

25. Selective Repeat Protocol (SRP) • Selective ACK’s sent by receiver identify specifically which frame(s) have been received correctly • In our example, the ACK would contain info that only packets #7 and #8 have already arrived at receiver • Sender only retransmits packets #6 and #9, and avoids resending #7 and #8 • “sliding” window in SRP actually becomes much more complicated than GBN - track “holes” btwn. acknowledged packets Window … … Prof. Rick Han, University of Colorado at Boulder

26. Link Layer vs. End-to-End Retransmission • Can retransmit end-to-end (at transport layer) as well as at data-link layer • Given link layer retransmission, why do you need end-to-end retransmission? • Packets can still be lost in intermediate nodes, e.g. routers • Given end-to-end retransmission, why retransmit at link-layer at all? • Performance? Prof. Rick Han, University of Colorado at Boulder

27. Other Protocol Design Issues • Flow control • Sequence # wrap-around • Connection establishment • Connection tear-down • State machine definition at sender and receiver endpoints of protocol Prof. Rick Han, University of Colorado at Boulder