Re: [tcpm] Ref to timestamp negotiation draft (expired)

[Neal Cardwell <[e-mail]>]

Hi Richard,

Thanks for your note. Unfortunately, I've been busy with other projects
recently (largely BBR) and haven't had time to read your draft on improving
timestamps (draft-scheffenegger-tcpm-timestamp-negotiation-05). It looks
like a very nice, thorough draft. So, rest assured that I will read it
before our team embarks on any draft related to the timestamp code we are
running within Google (which was written by Eric Dumazet, cc-ed).

thanks,
neal


On Tue, Dec 13, 2016 at 4:06 AM, Richard Scheffenegger <[e-mail]>
wrote:

> Hi Neal,
>
> did you have time to glance over the timestamp negotiation draft?
>
> Here is a brief abstract of some of the properties that the proposed
> negotiation scheme offers. However, at the time, there was too little
> interest in this (and no other vendor to support development efforts) thus
> it expired.
>
> a) no additional TCP Option space useage, particular in the initial SYN
>
> b) Up to 24 bits for arbitrary signalling - the draft uses 16 (
> https://tools.ietf.org/html/draft-scheffenegger-tcpm-
> timestamp-negotiation-05) to signal the timestamp interval; the value is
> encoded differently from a IEEE floating point representation to allow
> further freedom to indicate relative precision of the injected timestamp
> (ie. envision a NIC capable of hw clocking each segment in a TSO transfer,
> vs. using a coarse grained software clock in a virtual host)
>
> c) generic mechanism to make (parts of) the  timestamp useful for the
> receiver, allowing the sender to weakly authenticate returned timestamps
> (e.g. avoiding the cubic epoch exploit to game a sender by manipulating
> timestamps)
>
> d) In that basic version, 8 bits would still be available to provide the
> signals envisioned by your proposal for indicating Max ACK Delay - perhaps
> using a shift value offset by a constant biad as for the timestamp
> interval, more granualar signaling would be possible than in your proposal.
>
>
> Drawback of the scheme: duing 3WHS, the sender needs to keep state of the
> original TSval (which should be a non-issue for Linux stacks, and is
> manageable for byte-oriented stacks).
>
> Also, a small probability of falsely activating the TS negotiation.
> However, against servers on the internet, this probability is smaller than
> expected as TSval still relates linearly to system uptime, in most
> implementations; I've investigated this during writing intensively (not
> what you could do, though) - see section 5.3
>
> Re-reading, I see that my descriptive language  is perhaps not clear
> enough, the signals spoken about in the draft are always exchanged in a
> TSecr field of a TS Option, with the TSecr of the SYN/ACK being the XOR sum
> of the TSval from the SYN, plus the capabilites signal of the receiver...
>
> Best regards,
>   Richard
>
>
>
>
> Great. Thanks, Bob. We'll take a look at these...
>
> neal
>
> On Wed, Nov 16, 2016 at 9:59 AM, Bob Briscoe <[e-mail]> wrote:
>
> > Neil, [re-sending from correct address, so it is acceptable to the tcpm
> > list]
> >
> > As promised in the discussion just now about your timer negotiation talk
> > in tcpm, here's the previous draft on a similar subject:
> > Additional negotiation in the TCP Timestamp Option field during the TCP
> > handshake
> > <https://tools.ietf.org/html/draft-scheffenegger-tcpm-
> timestamp-negotiation-05>
> >
> > This was originally prompted by the research here (see section 3.1 for
> the
> > timestamp discussion), which you might also be interested in:
> > Chirping for Congestion Control - Implementation Feasibility
> > <http://www.bobbriscoe.net/pubs.html#chirp_impl>
> >
> >
> >
> > Bob
> >
> > PS. I can recommend a good search engine to find stuff like this :)
> >
> >
> > --
> > ________________________________________________________________
> > Bob Briscoe                               http://bobbriscoe.net/
> >
> >
>