Subject: Re: [tcpm] another basic option question - can TCP enable options on the SYN/ACK?

From: "Scheffenegger, Richard" <[email-masked]>
Date: Mon, 17 Nov 2014 06:11:56 +0000

Hi John,

Without any claim of completness or recentness:

liunx (at least used to) start talking / reflecting timestamps when they start appearing in mid-session. Simultaneously, a connection will not fail when timestamps suddenly disappear (which is, at least in 7323, in violation of PAWS. But i did some more extensive tests, which also pointed in the direction that paws is actually not active in linux, and the per-segment rtt sampling is done using per-segment state in the server. So in conclusion, timestamps appear to serve no purpose on linux...

Sorry tried to prune the original
Mail to the part i respond to, but this client cut that part out instead (iphone)

Best regards,
   Richard Scheffenegger

Am 24.10.2014 um 04:18 schrieb "John Leslie" <[email-masked]<mailto:[email-masked]>>:

Joe Touch <[email-masked]<mailto:[email-masked]>> wrote:
On 10/21/2014 8:54 PM, Yoshifumi Nishida wrote:

I'm wondering if all negotiations need to be negotiated.

The ones specified in RFC793 do not.

  (Of course!)

All others need to be negotiated *if* you care that the other end
supports it.

  Quite true. But note that it's easy to imagine options where one
endpoint _doesn't_ care if the other endpoint supports it.

  In fact, I expect to shortly submit a draft where this is the case.
An endpoint sending it announces its own support for it; but unless
the other endpoint also sends it, the first endpoint won't know whether
it has been acted on in any way.

That negotiation can happen at any point in the connection,

  Currently, most options _are_ noted in the originating SYN, for
several different reasons. First, the SYN and SYN-ACK are the only
place in a TCP connection that you know the options won't be quietly
dropped due to congestion. I am not aware
of much evidence either way on that.)

but if it doesn't happen during the opening handshake then the option
needs to be specified with its own 3WHS mechanism that can operate
independently of segment loss and retransmission (which, IMO, is a bad
idea).

  I don't agree it's a "bad" idea, but it surely is more complicated.

  Please note, however, that a 3-way HandShake isn't the only way to
synchronize sender's and receiver's views of an option being enabled.
(It is usually the best, but not the only...)

Some are confirmed in both directions (such as TS and WS), but others
may need to have a "response" to a specific "request".

  That indeed is common; and it becomes complicated because either the
request or the response can get dropped.

Finally, there are options that aren't as much negotiated as they are
either supported or not, e.g., MD5 and AO. There's no handshake. If the
option is required on that connection and isn't present, segments are
ignored anyway.

  True. And, IMHO, this is a rather important case.

I.e., a taxonomy should include, at a minimum:

   - always supported
       end-of-list
       NOP
       MSS

   - supported if enabled in both directions during the 3WHS
       TS, WS

   - request/response
       TFO, MPTCP, SACK

   - supported if enabled throughout the connection
       MD5, AO

  I'm hesitant to make statements like this: Each option should be
defined to detail its rules; and we can never hope to cover the entire
range of possible rules.

  Nonetheless, Joe is correct, so far as this goes.

--
John Leslie <[email-masked]<mailto:[email-masked]>>

_______________________________________________
tcpm mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/tcpm

---

From: Yuchung Cheng <[email-masked]>
Date: Mon, 17 Nov 2014 14:48:11 +0800

On Mon, Nov 17, 2014 at 2:11 PM, Scheffenegger, Richard <[email-masked]> wrote:
> liunx (at least used to) start talking / reflecting timestamps when they
> start appearing in mid-session. Simultaneously, a connection will not fail
> when timestamps suddenly disappear (which is, at least in 7323, in violation
> of PAWS. But i did some more extensive tests, which also pointed in the
> direction that paws is actually not active in linux, and the per-segment rtt
> sampling is done using per-segment state in the server. So in conclusion,
> timestamps appear to serve no purpose on linux...
?!

Linux TCP uses RFC1323 PAWS by default if TS is used. RFC7323 is just
published so please don't expect implementation will follow
immediately ok? please bring the specific tests you have to linux
netdev list or send them to me.

Linux also uses TS for RTT measurement if Karn's rule forbids taking
RTTs. TS is also critical for Eifel (undo) operations.

Both have been used for years.

> Am 24.10.2014 um 04:18 schrieb "John Leslie" <[email-masked]>:
>
> Joe Touch <[email-masked]> wrote:
>
> John Leslie <[email-masked]>
>
> [email-masked]
> [email-masked]