This method prevents duplicate packets from being

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: the sender knows about the receipt of the packet and has sent subsequent packets). This method prevents duplicate packets from being delivered to the receiving application. If a packet with sequence number rcv seqnum + 1 arrives, then send an ACK, deliver this packet to the application, and increment rcv seqnum. Note that a packet with sequence number greater than rcv seqnum + 1 should never arrive in this stop-and-wait protocol because that would imply that the sender got an ACK for rcv seqnum + 1, but such an ACK would have been sent only if the receiver got the packet. So, if such a packet were to arrive, then there must be a bug in the implementation of either the sender or the receiver in this stop-and-wait protocol. With this modification, the stop-and-wait protocol guarantees exactly-once delivery to the application.3 ￿ 20.2.3 Setting Timeouts The final design issue that we need to nail down in our stop-and-wait protocol is setting the value of the timeout. How soon after the transmission of a packet should the sender 3 We are assuming here that the sender and receiver nodes and processes don’t crash and restart; handling those cases make “exactly once” semantics considerably harder and requires stable storage that persists across crashes. SECTION 20.3. ADAPTIVE RTT ESTIMATION AND SETTING TIMEOUTS 5 Figure 20-2: RTT variations are pronounced in many networks. conclude that the packet (or the ACK) was lost, and go ahead and retransmit? One approach might be to use some constant, but then the question is what it should be set to. Too small, and the sender may end up retransmitting packets before giving enough time for the ACK for the original transmission to arrive, wasting network bandwidth. Too large, and one ends up wasting network bandwidth and simply idling before retransmitting. It should be clear that the natural time-scale in the protocol is the time between the transmission of a packet and the arrival of the ACK for the packet. This time is called the round-trip time, or RTT, and plays a crucial role in all reliable transport protocols. A good value of the timeout must clearly depend on the RTT; it makes no sense to use a timeout that is not bigger than the average RTT (and in fact, it must be quite a bit bigger than the average, as we’ll see). The other reason the RTT is an important concept is that the throughput (in packets per second) achieved by the stop-and-wait protocol is inversely proportional to the RTT (see Section 20.4). In fact, the throughput of many transport protocols depends on the RTT because the RTT is the time it takes to get feedback from the receiver about the fate of any given packet. The next section describes a procedure to estimate the RTT and set sender timeouts. This technique is general and applies to a variety of protocols, including both stop-andwait and sliding window. ￿ 20.3 Adaptive RTT Estimation and Setting Timeouts The RTT experienced by packets is variable because the delays in our network are variable. An example is shown in Figure 20-2, which shows the RTT of an Internet path between two hosts (blue) as a and the packet loss rate (red), both as a function of the time-of-day. The “rtt median-filtered” curve is the median RTT computed over a recent window of samples, and 6 CHAPTER 20. RELIABLE DATA TRANSPORT PROTOCOLS *+,-%-.(./0# *+&+(%,-)#'./0%01(123#4*567# !""#$%&'()# !""#$%&'()# Figure 20-3: RTT variations on a wide-area cellular wireless network (Verizon Wireless’s 3G CDMA Rev A service) across both idle periods and when data transfers are in progress, showing extremely high RTT values and high variability. The x-axis in both pictures is the RTT in milliseconds. The picture on the left shows the histogram (each bin plots the total probability of the RTT value falling within that bin), while the picture on the right is the cumulative distribution function (CDF). These delays suggest a poor network design with excessively long queues that do nothing more than cause delays to be very large. Of course, it means that the timeout method must adapt to these variations to the extent possible. (Data collected in November 2009 in Cambridge, MA and Belmont, MA.) you can see that even that varies quite a bit. Picking a timeout equal to simply the mean or median RTT is not a good idea because there will be many RTT samples that are larger than the mean (or median), and we don’t want to timeout prematurely and send spurious retransmissions. A good solution to the problem of picking the timeout value uses two tools we have seen earlier in the course: probability distributions (in our case, of the RTT estimates) and a simple filter design. Suppose we are interested in estimating a good timeout post facto: i.e., suppose we run the protocol and collect a sequence of RTT samples, how would one use these values to pick a good timeout? We can take all the RTT samples and plot them as a probability distribution, and then see how any given timeout value will have performed in terms of the probability of a spurious retransmission. If the timeout value is T , then this probability may be est...
View Full Document

This document was uploaded on 02/26/2014 for the course CS 6.02 at MIT.

Ask a homework question - tutors are online