Re: [tcpm] Disabling PAWS when possible

["Scheffenegger, Richard" <[e-mail]>]

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.
> 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




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

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.

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).


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

Best regards,
   Richard