Re: [tcpm] Disabling PAWS when possible

[Yoshifumi Nishida <[e-mail]>]

Hi Neal,

On Fri, Jun 22, 2018 at 9:56 AM, Neal Cardwell <[e-mail]> wrote:

> On Thu, Jun 21, 2018 at 2:50 AM Yoshifumi Nishida
> <[e-mail]> wrote:
> >
> > Hello,
> >
> > I have been thinking about PAWS and TS option for a while and prepared a
> simple short draft.
> > The basic ideas in the draft are like this.
> >
> > 1: There are several technologies (such as tcpinc, mptcp, tls) that can
> be used as a replacement of PAWS
> >     They can even provide stronger protections than PAWS, which might be
> able to contribute to recycling connections in TIME_WAIT.
> >
> > 2: Some implementations have records of transmission times on each
> segment which won't require TS option for RTTM.
> >
> > 3: When 1 is available, we don't have to put a TS option in every
> segment.
> >     Also, when 1 and 2 are available, we don't have to use TS option at
> all.
> >     Since we already have base technologies to replace PAWS and TS, all
> we need here is a simple signaling mechanism for feature negotiation.
> >
> > The draft is still very premature and I may overlook something, but it
> would be great if I could get some feedback.
> >
> > Thanks,
> > --
> > Yoshi
>
>
> Hi Yoshifumi,
>
> Thanks for this draft! Personally, I am fine with the general
> direction of disabling PAWS. But I would argue strongly for keeping
> TCP timestamps.


> The draft mentions "suppressing timestamp options" here:
>
>   ... The goal of the
>    proposal in the draft is to provide stronger protections for old
>    duplicated segments while facilitating the use of TCP option space by
>    suppressing timestamp options.
>
> I would argue strongly against suppressing/omitting TCP timestamp
> options, even if other mechanisms are available that subsume PAWS
> protection.
>
> There are a number of significant advantages to TCP timestamps, beyond
> PAWS:
>
> (1) quickly detecting spurious loss recoveries (using the Eifel
> algorithm - https://tools.ietf.org/html/rfc3522 - implemented by
> Linux)
>
> (2) architecturally, they allow TCP to have an approximation to the
> "packet number" that QUIC has (enabling (1)):
>   https://tools.ietf.org/html/draft-ietf-quic-recovery-08#section-2
>
> (3) allowing receivers to estimate RTT (used by Linux receive buffer
> autotuning)
>
> (4) allowing more precise bandwidth and RTT measurements by congestion
> control and passive monitoring systems
>
> And there are probably other nice uses that I'm forgetting. :-)
>

Thanks. These are very useful pointers for me to think about the draft
further.

I think you argument is fair enough.

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):
>
>   https://www.ietf.org/proceedings/97/slides/slides-
> 97-tcpm-tcp-options-for-low-latency-00.pdf
>
> 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
>

Yes, I am aware of this draft.
One thing I'm curious is that I thought servers in google may have records
of transmission time per packet as it's required by RACK.
However, this draft utilizes TS option with fine granularity.
Do you still need TS option even when you have records of transmission
time, or this feature is not used in the datacenter?

Anyway, both changing timestamp granularity and disabling PAWS change TS
option semantics.
It can make sense to have an unified negotiation scheme for both.
I will think about it more.

Thank you so much!
--
Yoshi