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