The answer turns out to be subtle its true that the

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: transmission, with probability ￿(1 − ￿), 1 we need two transmissions, and so on, giving us an expected number of transmissions of 1−￿ . If we make this number of transmissions, one packet is successfully sent and acknowledged. Hence, the utilization of the protocol can be at most 1 = 1 − ￿. 1 1−￿ If the sender picks a window size sufficiently larger than the bandwidth-minimumRTT product, so that at least bandwidth-minimum-RTT packets are in transit (unacknowledged) even in the face of data and ACK losses, then the protocol’s utilization will be close to the maximum value of 1 − ￿. Is a good timeout important for the sliding window protocol? Given that our sliding window protocol always sends a packet every time the sender gets an ACK, one might reasonably ask whether setting a good timeout value, which under even the best of conditions involves a hard trade-off, is essential. The answer turns out to be subtle: it’s true that the timeout can be quite large, because packets will continue to flow as long as some ACKs are arriving. However, as packets (or ACKs) get lost, the effective window size keeps falling, and eventually the protocol will stall until the sender retransmits. So one can’t ignore the task of picking a timeout altogether, but one can pick a more conservative (longer) timeout than in the stop-and-wait protocol. However, the longer the timeout, the bigger the stalls experienced by the receiver application—even though the receiver’s transport protocol would have received the packets, they can’t be delivered to the application because it wants the data to be delivered in order. Therefore, a good timeout is still quite useful, and the principles discussed in setting it are widely useful. Secondly, we note that the longer the timeout, the bigger the receiver’s buffer has to be when there are losses; in fact, in the worst case, there is no bound on how big the receiver’s buffer can get. To see why, think about what happens if we were unlucky and a packet with a particular sequence number kept getting lost, but everything else got through. 16 CHAPTER 20. RELIABLE DATA TRANSPORT PROTOCOLS The two factors mentioned above affect the throughput of the transport protocol, but the biggest consequence of a long timeout is the effect on the latency perceived by applications (or users). The reason is that packets are delivered in-order by the protocol to the application, which means that a missing packet with sequence number k will cause the application to stall, even though packets with sequence numbers larger than k have arrived and are in the transport protocol’s receiver buffer. Hence, an excessively long timeout hurts interactivity and the user’s experience. ￿ 20.6 Summary This lecture discussed the key concepts involved in the design on a reliable data transport protocol. The big idea is to use redundancy in the form of careful retransmissions, for which we developed the idea of using sequence numbers to uniquely identify packets and acknowledgments for the receiver to signal the successful reception of a packet to the sender. We discussed how the sender can set a good timeout, balancing between the ability to track a persistent change of the round-trip times against the ability to ignore nonpersistent glitches. The method to calculate the timeout involved estimating a smoothed mean and linear deviation using an exponential weighted moving average, which is a single real-zero low-pass filter. The timeout itself is set at the mean + 4 times the deviation to ensure that the tail probability of a spurious retransmission is small. We used these ideas in developing the simple stop-and-wait protocol. We then developed the idea of a sliding window to improve performance, and showed how to modify the sender and receiver to use this concept. Both the sender and receiver are now more complicated than in the stop-and-wait protocol, but when there are no losses, one can set the window size to the bandwidth-delay product and achieve high throughput in this protocol. ￿ Acknowledgments Thanks to Katrina LaCurts, Alexandre Megretski, and Sari Canelake for suggesting helpful improvements to this chapter. ￿ Problems and Questions 1. Consider a best-effort network with variable delays and losses. In such a network, Louis Reasoner suggests that the receiver does not need to send the sequence number in the ACK in a correctly implemented stop-and-wait protocol, where the sender sends packet k + 1 only after the ACK for packet k is received. Explain whether he is correct or not. 2. The 802.11 (WiFi) link-layer uses a stop-and-wait protocol to improve link reliability. The protocol works as follows: (a) The sender transmits packet k + 1 to the receiver as soon as it receives an ACK for the packet k. SECTION 20.6. SUMMARY 17 (b) After the receiver gets the entire packet, it computes a checksum (CRC). The processing time to compute the CRC is Tp and you may assume that it does not depend on the packet size. (c...
View Full Document

Ask a homework question - tutors are online