This preview shows page 1. Sign up to view the full content.
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 modiﬁcation, the stop-and-wait protocol guarantees exactly-once delivery to
20.2.3 Setting Timeouts The ﬁnal 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
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-ﬁltered” 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
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 ﬁlter 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.
- Fall '13