Subject: text on use of timestamps for 2.5g3g draft

From: "Andrei Gurtov" <[email-masked]>
Date: Tue, 22 Jan 2002 09:47:44 +0200

Hi,

 Please find below our joint text with Reiner on use of timestamps in 2.5g3g
draft.

Andrei

3.1.7. TCP timestamp option.

Traditionally, TCPs collect one RTT sample per window of data [38]. This can
lead to an underestimation of the RTT, and spurious timeouts on
bandwidth-dominated paths. This holds despite a conservative retransmit
timer such as the one proposed in RFC2988 [32]. In general, TCP connections
with a window larger than eight segments require more frequent RTT
measurements [S95]. Timing every segment can be implemented with or without
the TCP Timestamps option [5]. Using the TCP Timestamps option has the
advantage that retransmitted segments can be used for RTT measurement, which
is otherwise forbidden by Karn's algorithm [KP87]. Furthermore, the TCP
Timestamps option is the basis for detecting spurious retransmits using the
Eifel algorithm [17].

On paths where the packet transmission delay across the bottleneck link
dominates the path's RTT, the queuing delay and hence the RTT can increase
rapidly during the slow start phase. When RTT samples are collected once per
window, the RTO value applied just before taking a new RTT sample can
underestimate the current RTT. Experiments using NS2 show that in this case
a spurious timeout during fast recovery can occur even without any delay
spike [GU01]. Enabling timestamps significantly increases the maximum delay
spike tolerated by TCP without experiencing a spurious timeout. In summary,
timing every segment avoids the effect of an RTO lagging behind a rapidly
increasing RTT. This decreases the likelihood of a spurious timeout.
Additionally, timestamps reduce the likelihood of spurious timeouts due to
bandwidth oscillation [cdma2000].

The only problematic issue about using timestamp seems to be the 12 bytes
overhead introduced by carrying the TCP Timestamps option and padding in the
TCP header. For a small MTU size, it can present a considerable overhead.
For example, for an MTU of 296 bytes the added overhead is 4 %. For an MTU
of 1500 bytes, the added overhead is only 0.8 %. TCP/IP header compression
[RFC1144] does not support compressing headers with options. Thus, using the
TCP Timestamps option effectively disables it. However, in many cases TCP/IP
header compression is not used anyway due to poor performance in presence of
packet losses [LU99]. The IETF is currently specifying a robust TCP/IP
header compression scheme that supports TCP options [16,34].

The original specification of the timestamp option [5] may contain some
flaws. An update specification [B93] provides the necessary fixes. Ideas in
this expired draft appear in all current implementations of [5].

Recommendation: TCP SHOULD use the TCP Timestamps option. It allows better
RTT estimation, reduces the risk of spurious timeouts, and enables the
detection of spurious retransmits using the Eifel algorithm.

References

[cdma2000] F. Khafizov, M. Yavuz, TCP over CDMA2000 networks,
draft-khafizov-pilc-cdma2000-00.txt

[KP87] P. Karn, C. Partridge, Improving Round-Trip Time Estimates in
Reliable Transport Protocols, In Proceedings of ACM SIGCOMM 87.

[LU99] R. Ludwig, B. Rathonyi, A. Konrad, K. Oden, and A. Joseph.
Multi-layer tracing of TCP over a reliable wireless link. In Proceedings of
the ACM SIGMETRICS, May 1999.

[GU01] A. Gurtov, Making TCP Robust Against Delay Spikes, University of
Helsinki, Department of Computer Science, Series of Publications C, No
C-2001-53, November 2001. Available at
http://www.cs.helsinki.fi/u/gurtov/papers/report01.html

[RFC1144] V. Jacobson, Compressing TCP/IP Headers for Low-Speed Serial
Links, RFC1144, February 1990.

[S95] W. Stevens, TCP/IP Illustrated, Volume 1; The Protocols, Addison
Wesley, 1995.

[B93] R. T. Braden, TCP Extensions for High Performance: An Update, Internet
Draft, June 1993. http://www.kohala.com/start/tcplw-extensions.txt

---

From: Noritoshi Demizu <[email-masked]>
Date: Sun, 27 Jan 2002 07:47:12 +0900

Andrei,

 > this expired draft appear in all current implementations of [5].

Is the last statement correct?

In your mail on Jan 6, 2002, I thought you mentioned that
Linux follows RFC1323 without the modification of [B93].
NetBSD still checks Last.ACK.sent < SEG.SEQ + SEG.LEN.
FreeBSD does not check SEG.TSval >= TSrecent.
OpenBSD follows the modification of [B93].
I do not know of other implementations and simulators.

Since Linux is used widely, is it better to replace
the word "all" to something like "many" or "some" ?

 > [5]   Jacobson, V., Bdaden, R. and D. Borman, "TCP Extensions for
 >       High Performance", RFC 1323, May 1992.

Regards,
Noritoshi Demizu

---

From: "Andrei Gurtov" <[email-masked]>
Date: Sun, 27 Jan 2002 13:51:51 +0200

Noritoshi-

>  > this expired draft appear in all current implementations of [5].
......
> the word "all" to something like "many" or "some" ?

You are very right here. In fact, after discussing with Alexey Kuznetsov
(Linux TCP/IP implementer) and Reiner the issue about this update became
more controversial. According to Alexey, older Linux versions implemented
the update, but the kernel was reverted back to rfc1323 in version 2.4. The
reason is vulnerability to spoofing attacks since this update allows
changing TCP state by out-of-window segments. Also, we concluded with Reiner
that the 'failure case' for Eifel caused by echoing of old timestamps is in
fact a good thing. Hence, I'm more thinking in favor of the original rfc1323
at the moment. Because of that I suggest some neutral text that replaces the
quote above.

---
The original definition of the timestamp option [5] specifies that duplicate
segments below cumulative ACK do not update the cached timestamp value at
the receiver. This may lead to overestimating of RTT for retransmitted
segments. A possible solution [B93] allows the receiver to use a more recent
timestamp from a duplicate segment. However, this suggestion allows for
spoofing attacks at the TCP receiver. Therefore,  careful consideration is
needed in implementing this solution.
---

rgds,
Andrei