This preview shows page 1. Sign up to view the full content.
Unformatted text preview: transmission, with probability (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− If the sender picks a window size sufﬁciently 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 ﬂow 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
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 ﬁlter. 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.
View Full Document
- Fall '13