Unformatted text preview: imated as the area under the curve to the right of “T” in the picture on the
left of Figure 203, 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 203, the probability of a spurious retransmission may be assumed to be the value
of the yaxis corresponding to a value of T on the xaxis.
Realworld distributions of RTT are not actually Gaussian, but an interesting property
of all distributions is that if you pick a threshold that is a sufﬁcient 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 cutoff 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 biterror 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 postfacto 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” ﬁeld.
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 ﬁrst 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 ﬁltering 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 lowpass ﬁlter (LPF) does. 8 CHAPTER 20. RELIABLE DATA TRANSPORT PROTOCOLS Figure 204: Frequency response of the exponential weighted moving average lowpass ﬁlter. As α decreases, the lowpass ﬁlter 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 lowpass ﬁlter, 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 ﬁlter 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.
 Fall '13
 HariBalakrishnan

Click to edit the document details