Equivalently if we look at the cumulative

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: imated as the area under the curve to the right of “T” in the picture on the left of Figure 20-3, which shows the histogram of RTT samples. Equivalently, if we look at the cumulative distribution function of the RTT samples (the picture on the right of Figure 20-3, the probability of a spurious retransmission may be assumed to be the value of the y-axis corresponding to a value of T on the x-axis. Real-world distributions of RTT are not actually Gaussian, but an interesting property of all distributions is that if you pick a threshold that is a sufficient number of standard deviations greater than the mean, the tail probability of a sample exceeding that threshold can be made arbitrarily small. (For the mathematically inclined, a useful result for arbitrary distributions is Chebyshev’s inequality, which you might have seen in other courses already (or soon will): P(| X − µ| ≥ kσ ) ≤ 1/k2 , where µ is the mean and σ the standard deviation of the distribution. For Gaussians, the tail probability falls off much faster than SECTION 20.3. ADAPTIVE RTT ESTIMATION AND SETTING TIMEOUTS 7 1/k2 ; for instance, when k = 2, the Gaussian tail probability is only about 0.05 and when k = 3, the tail probability is about 0.003.) The protocol designer can use past RTT samples to determine an RTT cut-off so that only a small fraction f of the samples are larger. The choice of f depends on what spurious retransmission rate one is willing to tolerate, and depending on the protocol, the cost of such an action might be small or large. Empirically, Internet transport protocols tend to be conservative and use k = 4, in an attempt to make the likelihood of a spurious retransmission very small, because it turns out that the cost of doing one on an already congested network is rather large. Notice that this approach is similar to something we did earlier in the course when we estimated the bit-error rate from the probability density function of voltage samples, where values above (or below) a threshold would correspond to a bit error. In our case, the “error” is a spurious retransmission. So far, we have discussed how to set the timeout in a post-facto way, assuming we knew what the RTT samples were. We now need to talk about two important issues to complete the story: 1. How can the sender obtain RTT estimates? 2. How should the sender estimate the mean and deviation and pick a suitable timeout? Obtaining RTT estimates. If the sender keeps track of when it sent each packet, then it can obtain a sample of the RTT when it gets an ACK for the packet. The RTT sample is simply the difference in time between when the ACK arrived and when the packet was sent. An elegant way to keep track of this information in a protocol is for the sender to include the current time in the header of each packet that it sends in a “timestamp” field. The receiver then simply echoes this time in its ACK. When the sender gets an ACK, it just has to consult the clock for the current time, and subtract the echoed timestamp to obtain an RTT sample. Calculating the timeout. As explained above, our plan is to pick a timeout that uses both the average and deviation of the RTT sample distribution. The sender must take two factors into account while estimating these values: 1. It must not get swayed by infrequent samples that are either too large or too small. That is, it must employ some sort of “smoothing”. 2. It must weigh more recent estimates higher than old ones, because network conditions could have changed over multiple RTTs. Thus, what we want is a way to track changing conditions, while at the same time not being swayed by sudden changes that don’t persist. Let’s look at the first requirement. Given a sequence of RTT samples, r0 , r1 , r2 , . . . , rn , we want a sequence of smoothed outputs, s0 , s1 , s2 , . . . , sn that avoids being swayed by sudden changes that don’t persist. This problem sounds like a filtering problem, which we have studied earlier. The difference, of course, is that we aren’t applying it to frequency division multiplexing, but the underlying problem is what a low-pass filter (LPF) does. 8 CHAPTER 20. RELIABLE DATA TRANSPORT PROTOCOLS Figure 20-4: Frequency response of the exponential weighted moving average low-pass filter. As α decreases, the low-pass filter becomes even more pronounced. The graph shows the response for α = 0.9, 0.5, 0.1, going from top to bottom. A simple LPF that provides what we need has the following form: sn = αrn + (1 − α)sn−1 , (20.1) where 0 < α < 1. To see why Eq. (20.1) is a low-pass filter, let’s write down the frequency response, H (e jΩ ). We know that if rn = e jΩn , then sn = H (e jΩ )e jΩn . Letting z = e jΩ , we can rewrite Eq. (20.1) as H (e jΩ )zn = α zn + (1 − α) H (e jΩ )z(n−1) , which then gives us H ( e jΩ ) = αz , z − (1 − α) (20.2) This filter has a single real pole, and is stable when 0 < α < 1. The peak of...
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