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