echo requests and responses (that is,
ping), but this incurs additional network load. In some cases ICMP traffic
is deprioritized, dropped completely,
or routed over a different path to TCP
traffic. If none of this is true, there is
still the possibility that the RTT is being measured to a Network Address
Translator (NAT) and not the end host
exchanging data.
Another possible solution for measuring network RTT is to measure the
application-layer responsiveness. This,
however, implies an application-spe-cific, ad hoc measurement performed
by embedding IDs or timestamps into
the TCP bytestream, which may give a
misleading, inflated measurement for
network RTT, depending on network
conditions (more on this later).
Neither of these solutions is to-
tally satisfactory because neither is
guaranteed to measure the network
RTT that affects application traffic.
The timestamp information carried
in TCP headers, however, offers an-
other solution: it is effectively a net-
work-layer RTT measurement that
passes through most middleboxes
such as NATs and firewalls and mea-
sures the full-path RTT between both
hosts on a connection. This informa-
tion provides the only noncustom
RTT estimation solution available to
end hosts. Tools such as tcptrace can
calculate RTT using this state, but
any software that can inspect packet
headers (usually accomplished via
libpcap) or that can interrogate the
local system for such kernel state can
passively gather network RTTs for all
active connections.
The key differences between these
measurements and how differing network conditions affect them are not
obvious. The purpose of this article is
to discuss and demonstrate the passive RTT measurements possible using
TCP traffic.
Background
TCP offers a reliable bytestream to the
applications that use it; applications
send arbitrary amounts of data, and
the TCP layer sends this as a series of
segments with sequence numbers and
payload lengths indicating the chunk
of the bytestream each segment represents. To achieve an ordered byte
stream, TCP retransmits segments if
they go missing between the source
and destination (or, if an acknowledgment for a received segment goes
missing between the destination and
the source). To improve performance
in all network conditions, the TCP
stack measures RTT between it and
the other host on every connection to
allow it to optimize its retransmission
timeout (RTO) appropriately and optimize the time taken to recover from a
loss event.
The original TCP specification con-
tained no mandatory, dedicated RTT
calculation mechanism. Instead, TCP
stacks attempted to calculate RTTs by
observing the time at which a sequence
number was sent and correlating that
with a corresponding acknowledgment.
Calculation of RTTs using this mecha-
nism in the presence of packet loss,
however, makes accurate measure-
ment impossible.
13 TCP timestamps
were defined to permit this calculation
independently at both ends of a con-
nection while data is being exchanged
between the two hosts. TCP timestamps
offer a mechanism for calculating RTT
that is independent of sequence num-
bers and acknowledgments.
The algorithm for calculating RTT
from a TCP flow between two hosts,
documented in RFC 1323,
3 is commonly used by both end hosts on a connection to refine the RTO to improve the
performance of TCP in the presence
of loss. The mechanism is enabled by
default in modern operating systems
and is rarely blocked by firewalls, and
thus appears in most TCP flows; the
TCP Timestamp option is known to be
widely deployed in the wild.
5
RTT is calculated continuously for
each connection for as long as data is
exchanged on those connections. TCP
calculates RTT for packets exchanged
on a per-connection basis and computes the exponential moving average
of these measurements, referred to
as the smoothed RTT (SRTT). The TCP
stack also maintains the variance in
the measured RTT, the RTTVAR. The
SRTT that the TCP stack calculates for a
connection determines the RTO value.
Given variables G, which is the system
clock granularity, and K, which is set
to 4,
8 the RTO is calculated as follows:
RTO = SRTT + max(G,K RTTVAR)
The R TO is used to optimize the time
the TCP stack waits, having transmitted a TCP segment, for a corresponding acknowledgment prior to retrying
the send operation. Accurate measurements of RTT between two hosts allow
TCP to tune its RTO accurately for each
active connection.
Understanding the state contained
within the TCP headers carried in
most TCP traffic can help application designers or network operators
understand the network RTTs experienced by application traffic. Many applications with real-time constraints
use TCP to transport their traffic,
which is acceptable within certain
bounds.
1 It is useful to understand
figure 1. simplified demonstration of tCP timestamp exchange.
b
1
2
3
4
5
6
7
A