Chapter 2 Designing Reliable Protocols Professor Rick Han University of Colorado at Boulder

Prof. Rick Han, University of Colorado at Boulder Announcements Moved to ECCR 265 Larger classroom => graduate students on wait list may take the class If not enough textbooks, send me 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 Recap of Previous Lecture Layer 1 Layer 2 Host A 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

Prof. Rick Han, University of Colorado at Boulder 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, , even playback video Can incur too much delay for interactive audio/video

Prof. Rick Han, University of Colorado at Boulder 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 SenderReceiver #5 … Got #5

Prof. Rick Han, University of Colorado at Boulder 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 SenderReceiver #6 … Got #6

Prof. Rick Han, University of Colorado at Boulder 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 SenderReceiver #5 … Got #5

Prof. Rick Han, University of Colorado at Boulder 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 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 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 SenderReceiver #6 … Got #6 … Got <#7

Prof. Rick Han, University of Colorado at Boulder 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 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 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 Sender Receiver Frame Ack Next frame Ack Timeout Period RTT time

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

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

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

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

Prof. Rick Han, University of Colorado at Boulder 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*Bandwidth product = 67.5 Kb ≈ 8 KB. “pipe size” If frame size = 1 KB, then use only 1/8 of bandwidth SenderReceiver Frame #1 ACK #1 Frame #2 ACK #2 RTT time

Prof. Rick Han, University of Colorado at Boulder “Keep the Pipe Full” During one RTT, send N packets Example: 1.5 Mbps link with RTT 45 ms => a Delay*Bandwidth product = 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! SenderReceiver RTT time Frame #1 Frame #2 Frame #3 ACK #3 ACK #2 ACK #1

Prof. Rick Han, University of Colorado at Boulder 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) Sliding window: When ACK arrives, slide LAR and LFS to right LFS – LAR <= SWS (= delay*BW product?) Retransmit entire window …… LARLFS SWS

Prof. Rick Han, University of Colorado at Boulder 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) 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 …… LFRLAF RWS

Prof. Rick Han, University of Colorado at Boulder 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. …… LFR=5LAF=9 RWS=4 LFR’=8LAF’=12

Prof. Rick Han, University of Colorado at Boulder 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=5LFS=11 SWS=6 LAR’=8LFS’=14

Prof. Rick Han, University of Colorado at Boulder 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 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 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 Other Protocol Design Issues Flow control Sequence # wrap-around Connection establishment Connection tear-down State machine definition at sender and receiver endpoints of protocol