Re: [tcpm] Disabling PAWS when possible

["Brian Trammell (IETF)" <[e-mail]>]

hi Yoshi, all,

I'm intrigued in general by the possibility of disabling PAWS in certain circumstances, but (not just as a co-author of the TS negotiation draft Richard mentions ;) ) am also concerned about the secondary effects of shutting down timestamps, especially on passive latency measurement.

On the other hand, the current timestamp facility is both high-overhead and leaks a fair amount of information about the identity of the sending host (by exposing clock drift in the simplest of implementations), so alternatives would be useful, even in the case that one only cares about passive measurability.

There would be another way to disable PAWS while supporting passive latency measurement and addressing issues with timestamps as presently exposed: add a latency spin signal (i.e., the QUIC spin bit) to TCP in the three reserved bits next to the to-be-reassigned nonce sum. See https://tools.ietf.org/html/draft-trammell-tsvwg-spin.

This is only a semi-serious suggestion at this point: we wrote this up mainly since we (well, Mirja did all the implementation) had already added it to TCP in order to have a stable platform for experimenting with passive measurement techniques for the signal itself, as QUIC remains under construction. But it's not a *terrible* idea, especially if a consensus emerges that selectively disabling PAWS is also not a terrible idea.

(more inline)

> On 27 Jun 2018, at 06:05, Yoshifumi Nishida <[e-mail]> wrote:
> 
> Hi Richard,
> 
> On Mon, Jun 25, 2018 at 2:32 AM, Scheffenegger, Richard <[e-mail]> wrote:
> Hi Yoshifumi, Neal,
> 
> 
> Am 23.06.2018 um 01:23 schrieb Yoshifumi Nishida:
> 
> My intention is to relax the requirement "The TSopt MUST be sent in every non-<RST> segment for the duration of the connection" in RFC7323
> so that TSopt can be sent at arbitrary intervals. Arbitrary intervals can contain infinite interval, but you can only do so when you really want, otherwise you shouldn't.

This relaxation would allow a fix for the average overhead problem, and would reduce (but not eliminate) the data available for drift-based fingerprinting approaches, so IMO it's equivalent in utility to the spin bit, with the advantage that it doesn't use weird new flags in the header (and the disadvantage that it changes the semantic of an old option in ways that certain middleboxes might not like)...

> So, disabling TS entirely is just an option.
> 
> 
>   >  From my perspective, one huge advantage from disabling PAWS is that it
>   >  enables the timestamps to be an opaque identifier, so that the sender
>   >  can use them in any way it chooses. In particular, it would allow the
>   >  sender to use microsecond timestamps, without worrying about the
>   >  remote side dropping packets due to PAWS checks. This was the main
>   >  challenge we found in implementing microsecond TCP timestamps inside
>   >  Google datacenters, as we discussed at TCPM a while back (slide 6):
> 
> [...]
> 
> >   >  My main comment would be, if some proposal is going to
> >   >  standardize a negotiation scheme for using timestamps but
> >   >  disabling PAWS, IMHO there could be huge value in having that
> >   >  negotiation mechanism optionally specify the semantics of a
> >   >  sender's timestamp values, so that congestion control and
> >   >  passive monitoring tools could make use of the timestamps
> >   >  for bandwidth and latency measurements. This could be
> >   >  something as simple as 2 bits, e.g.:
> >   >
> >   >  bits : meaning
> >   >   00: traditional RFC 7323 timestamps: use PAWS
> >   >   01: microsecond timestamps, disable PAWS
> >   >   10: millisecond timestamps, disable PAWS
> >   >   11: values with other semantics, disable PAWS
> 

(not sure who i'm replying to here -- apple/gmail incompatibilities)

> TSopt is today semi-opaque - a receiver can not rely on timestamps to have a specific granularity or monotonicity today.

No, but in most implementations constant granularity (driven from some time or interrupt counter) still holds, no?

> It seems to me, that two paths should be discussed here: making TSopt completely opaque - that is, disallowing the receiver to make any use of it, only allowing it to be a signal from the sender in the past (1RTT) to the sender in the future.

by "disallowing" do you mean "a sternly worded MUST" or do you mean "encryption"? One of these will work better than the other. ;)

> Or making it more transparent, but disabling PAWS - meaning that the content of TSopt can actually be interpreted by a receiver, potentially allowing additional capabilities (one-way delay variation measurement, "TCP Chirp", springs to mind).

I'm obviously more of a fan of this approach.

Cheers,

Brian

> Provided the clock granularity is fine enough, both points (unique packet identifier, and allowing fine-grained timing data to be extracted) could be done.
> 
> Some of these functionalities were touched upon in this draft some time ago:
> https://tools.ietf.org/html/draft-scheffenegger-tcpm-timestamp-negotiation-05
> 
> Yep, signaling mechanism to change the semantics of TS is an interesting point for discussions.
> We can extend TS option like you proposed in the draft or integrating into existing negotiation mechanisms or developing a new option.
> Developing a new option seems to be a straightforward approach, but it will consume extra option space and may be discarded by middleboxes.
> 
> BTW, the draft above is cited in the draft as a good starting point of discussion.
> --
> Yoshi
> 
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm