ip tcp timestamp

I have seen this command a few times, today I am going to look into it and see what it does. Also, this is probably a classic CCIE lab gotcha.

From the Cisco documentation:

The TCP time-stamp option provides better TCP round-trip time measurements. Because the time stamps are always sent and echoed in both directions and the time-stamp value in the header is always changing, TCP header compression will not compress the outgoing packet. To allow TCP header compression over a serial link, the TCP time-stamp option is disabled.

Thats look like a classic CCIE lab exam question to me

Refer to RFC 1323 for more detailed information on TCP time stamp. (OK, I will cover that in a minute).

To enable TCP time stamp, use the following command in global configuration mode:

Router(config)# ip tcp timestamp

If you want to use TCP header compression over a serial line, TCP time stamp and TCP selective acknowledgment must be disabled. Both features are disabled by default. To disable TCP selective acknowledgment once it is enabled, see the previous “Enabling TCP Selective Acknowledgment” section.

Even trickier.

Extract from the RFC

Abstract

This memo presents a set of TCP extensions to improve performance
over large bandwidth*delay product paths and to provide reliable
operation over very high-speed paths. It defines new TCP options for
scaled windows and timestamps, which are designed to provide
compatible interworking with TCP’s that do not implement the
extensions. The timestamps are used for two distinct mechanisms:
RTTM (Round Trip Time Measurement) and PAWS (Protect Against Wrapped
Sequences). Selective acknowledgments are not included in this memo.

What does it mean ?

Stephens TCP/IP Illustrated Vol2 says:

The timestamp option lets the sender place a timestamp value in every segment. The receiver reflects this value in the acknowledgment, allowing the sender to calculate an RTT for each received ACK. (We must say “each received ACK” and not “each segment” since TCP normally acknowledges multiple segments per ACK.) We said that many current implementations only measure one RTT per window, which is OK for windows containing eight segments. Larger window sizes, however, require better RTT calculations

Paraphrasing RFC 1323

3. RTTM: ROUND-TRIP TIME MEASUREMENT

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 (Round-Trip 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.

Conclusion

So from my reading, by forcing a RTT into every packet instead one packet per TCP Window we will improve the performance of the TCP congestion algorithm. This works best on high performance links (that is, high speed and low latency) because the TCP Window get (relatively) very large, thus the RTT measurement could easily not be accurately peaky conditions on the circuit.

This would only apply to packets originated from the router control plane and not apply to packets from external devices (aka servers and workstations) so would only be useful for specific applications in the real world.

So I can think of the following cases when this would be useful:

• tunnel interfaces on gigabit services
• using a router as packet generator
• BGP peering – large number of routes to exchange, this option might improve the connection establishment time
• SSL VPN’s – might be able to improve application response in a high speed enterprise network

If you can think of any others, please let me know in the comments.