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

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

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