Re: [tcpm] usage for timestamp options in the wild

[Yuchung Cheng <[e-mail]>]

On Wed, Sep 26, 2018 at 12:43 PM, Yoshifumi Nishida
<[e-mail]> wrote:
>
>
>
> On Wed, Sep 26, 2018 at 11:37 AM, Yuchung Cheng <[e-mail]> wrote:
>>
>> On Wed, Sep 26, 2018 at 11:21 AM, Praveen Balasubramanian
>> <pravb=[e-mail]> wrote:
>> >
>> > Windows doesn’t do timestamp option by default. It’s 10 byte per packet overhead for marginal benefits.
>> >
>> >
>> >
>> > From: tcpm <[e-mail]> On Behalf Of Yoshifumi Nishida
>> > Sent: Wednesday, September 26, 2018 10:49 AM
>> > To: [e-mail]
>> > Subject: [tcpm] usage for timestamp options in the wild
>> >
>> >
>> >
>> > Hello,
>> >
>> > this is just out of my curiosity.
>> >
>> > I've checked traffic archives in CAIDA (https://data.caida.org/datasets/) and WIDE (http://mawi.wide..ad.jp/mawi/) on a whim and tried to see how many connections utilize timestamps.
>> >
>> >
>> >
>> > As far as I've checked some archives recently captured, it seems that around 60-70% TCP connections use timestamp option. But, this ratio seems to be a bit lower as I thought most of implementations these days support TS option and activate it by default.
>> how recent are the archives?
>
>
> They are 2018 data.
There's some number dated in 2011

"2. GOOGLE MEASUREMENTS We sampled TCP statistics on unmodified Google
Web servers world-wide for one week in May 2011. The servers use a
recent version of Linux 2.6 with settings listed in Table 4. The
servers do not include the changes proposed in this paper. The global
statistics for interactive Web services are summarized in Table 1.
Among the billions of connections sampled, 96% of the connections
negotiated SACK but only 12% of the connections negotiated Timestamps.
The majority of clients are Microsoft Windows which by default do not
use TCP Timestamps."
https://storage.googleapis.com/pub-tools-public-publication-data/pdf/37486.pdf

While this is comparing apple (google) to oranges (caida), I would say
70% is already a significant jump.


However I am sensing that the value of TCP timestamp options is
under-valued - Linux for example uses TS for many things:

1. RTT estimation on retransmission - this is crucial when a TCP is in
constant recovery mode such as encountering a traffic policer. Note
that the standard ACK time approach no longer works if any sequence
acked has been transmitted, thus RTO may stale during extended
recovery period.

2. Undo operations (i.e. TCP Eifel RFC4015) requires TCP timestamps -
being able to detect false reactions to losses is particularly key for
"loss-based" congestion control. Such false positives are common in
wireless or even wired networks due to all sorts of dark queues and L2
optimizations. While DSACK and F-RTO can also be used to detect false
recoveries - both of them take at least one more round-trip and/or
require new application data, while timestamp can detect false
retransmission instantly on the original ACK

3. Receiver buffer auto-tuning uses TCP ACKs' TS value to echo to
measure RTT from the receiver to tune the buffer size.

4. Potentially TCP timestamps being generated with known units, can be
used to gauge the data arrival rate. The measurement can be valuable
for congestion control b/c it's not subject to hectic ACK delays in
modern networks. I know folks at NetFlix is doing some deep research
into this aspect.


QUIC has emphasized the importance of unique packet identifier - TCP
TS provides a close equivalent and is super useful, especially w/ more
precision / unit vs an opaque value.

>>
>>
>> AFAIK TS is enabled by default on Linux, FreeBSD, and iOS. Linux has
>> that by default more than a decade
>
>
> that's why I was wondering.
> --
> Yoshi
>