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.
how the bytestream semantic can affect real-time performance.
TCP timestamps are optional fields
in the TCP header, so although they are
extremely useful and carried in most
traffic, they are not strictly required for
TCP to function. The values are held in
two four-byte header fields: Timestamp
Value (TSval) and Timestamp Echo Reply (TSecr). Both hosts involved in the
connection emit TSval timestamps
to the other host whenever a TCP segment is transmitted, and they await
the corresponding TSecr in return. The
time difference measured between
first emitting a TSval and receiving it in
a TSecr is the TCP stack’s best guess as
to RTT. Timestamp here is an arbitrary
value that increments at the granularity of the local system clock; it is not a
timestamp that can be interpreted independently, such as number of seconds since the epoch.
By way of example, in Figure 1, time
progresses from top to bottom, and
the horizontal lines indicate real-time
incrementing (for example, in milliseconds). Two hosts, A and B, have an
open connection and are exchanging
packets. In reality the two hosts have
differing clocks, but for simplicity assume they are perfectly synchronized.
The example operates as follows:
Host A emits a TCP segment that
contains the timestamp options
TSval = 1, TSecr = 0
TSecr is set to 0 because no TSval from
B has been observed at A; this usually
indicates A is opening a connection to
B. Host B receives this timestamp at
time 1; at time 2, host B emits a TCP
segment back to A, which contains the
values
TSval = 2, TSecr = TSvalA = 1
These are received at host A at time 3.
Given this echoed value and the current time, host A knows that the RTT in
this instance is approximately 2ms.
Subsequently, the next two segments
that A emits both carry the values:
TSval = 3, TSecr = TSvalB = 2
The first of these is received at host B at
time 4, so host B can also calculate an
RTT of 2ms. Given the two echoes of
the same timestamp received, the mini-
mum duration is assumed to be closest
to actual network delay; if network de-
lay changes, future exchanges will mea-
sure this. Continuously sending values
to the other host and noting the mini-
mum time until the echo reply contain-
ing that value is received allows each
end host to determine the RT T between
it and the other host on a connection.
The caveat is that for a TSval to be
considered useful, the TCP segment
must be carrying data from the appli-
cation. TCP segments can legitimately
carry a zero-byte payload, most com-
monly when acknowledging a data
segment, or when TCP keepalives are
enabled. By requiring the only valid
TSvals come from TCP segments car-
rying data, the algorithm is less likely
to measure breaks in the communica-
tion between the hosts, where data ex-
change pauses for a time, then restarts
using the last received TSval as the TSe-
cr. This also implies that on a TCP flow
in which data is exchanged exclusively
in one direction, only one of the hosts
will be able to calculate the RTT. Usual-
ly, however, there is some application
layer chatter in both directions.
Finally, RTT calculation can be
performed on any host that is forwarding traffic, not just end hosts,
so full-path RTTs on all connections
within a network can be calculated
from its gateway host, for example.
All that is necessary to compute accurate RTTs is that both directions
of a connection pass through the
monitoring host. Whether this is the
case often relies on the network architecture, but it is known that paths
on the Internet are normally not symmetric.
2 Running this algorithm on a
gateway node for a network through
which all traffic passes, however, allows for the RTT calculation to take
place passively on all connections
from just one location.
Demonstrating Rtt measurements
The network is a shared resource, and
multiple factors can affect TCP RTT
calculation. This section broadly covers some of these factors and demonstrates where the TCP RTT calculation
differs from the RTT perceived by applications. The aim is to demonstrate
parity with ICMP’s RTT estimations,
assuming all else is equal, and how
HIGH-FREQUENCY
TRADING