3.1 Introduction
Connected: An Internet Encyclopedia
3.1 Introduction
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 1323
Up:
3. RTTM: ROUNDTRIP TIME MEASUREMENT
Prev: 3. RTTM: ROUNDTRIP TIME MEASUREMENT
Next: 3.2 TCP Timestamps Option
3.1 Introduction
3.1 Introduction
Accurate and current RTT estimates are necessary to adapt to
changing traffic conditions and to avoid an instability known as
"congestion collapse" [Nagle84] in a busy network. However,
accurate measurement of RTT may be difficult both in theory and in
implementation.
Many TCP implementations base their RTT measurements upon a sample
of only one packet per window. While this yields an adequate
approximation to the RTT for small windows, it results in an
unacceptably poor RTT estimate for an LFN. If we look at RTT
estimation as a signal processing problem (which it is), a data
signal at some frequency, the packet rate, is being sampled at a
lower frequency, the window rate. This lower sampling frequency
violates Nyquist's criteria and may therefore introduce "aliasing"
artifacts into the estimated RTT [Hamming77].
A good RTT estimator with a conservative retransmission timeout
calculation can tolerate aliasing when the sampling frequency is
"close" to the data frequency. For example, with a window of 8
packets, the sample rate is 1/8 the data frequency  less than an
order of magnitude different. However, when the window is tens or
hundreds of packets, the RTT estimator may be seriously in error,
resulting in spurious retransmissions.
If there are dropped packets, the problem becomes worse. Zhang
[Zhang86], Jain [Jain86] and Karn [Karn87] have shown that it is
not possible to accumulate reliable RTT estimates if retransmitted
segments are included in the estimate. Since a full window of
data will have been transmitted prior to a retransmission, all of
the segments in that window will have to be ACKed before the next
RTT sample can be taken. This means at least an additional
window's worth of time between RTT measurements and, as the error
rate approaches one per window of data (e.g., 10**6 errors per
bit for the Wideband satellite network), it becomes effectively
impossible to obtain a valid RTT measurement.
A solution to these problems, which actually simplifies the sender
substantially, is as follows: using TCP options, the sender places
a timestamp in each data segment, and the receiver reflects these
timestamps back in ACK segments. Then a single subtract gives the
sender an accurate RTT measurement for every ACK segment (which
will correspond to every other data segment, with a sensible
receiver). We call this the RTTM (RoundTrip Time Measurement)
mechanism.
It is vitally important to use the RTTM mechanism with big
windows; otherwise, the door is opened to some dangerous
instabilities due to aliasing. Furthermore, the option is
probably useful for all TCP's, since it simplifies the sender.
Next: 3.2 TCP Timestamps Option
Connected: An Internet Encyclopedia
3.1 Introduction
