Re: [tcpm] More TCP option space in a SYN: draft-briscoe-tcpm-syn-op-sis-02

[John Leslie <[e-mail]>]

Bob Briscoe <[e-mail]> wrote:
> 
> I've got a bit behind in this conversation - I'm on another part of 
> my job at the mo. So apologies that my response to this old posting 
> on this thread arrives out of order.

   I've been over-extended myself this past week. :^(

   I'm not sure this still deserves a response, but I'd like to cover
a few points...

> At 20:53 26/09/2014, John Leslie wrote:
>> Bob Briscoe <[e-mail]> wrote:
>>> At 15:50 26/09/2014, John Leslie wrote:
>>>> Bob Briscoe <[e-mail]> wrote:
> 
>>>> For any Experimental-status document, I recommend:
>>>>...
>>>> - that any acknowledgment of extra option space in an initial SYN
>>>>   include a checksum or hash of the extra options to ensure that both
>>>>   ends have the same view of what options have been signaled;
>>>
>>> Not convinced on this one. Each TCP option has its own way for the
>>> 'server' to confirm whether it supports an option requested by the
>>> client.
>>
>> And this one should also have its own way. I see so many things that
>> could get in the way that I _strongly_ recommend some checksum/hash.
>>
>>> And support for the option to extend the option space is confirmed by
>>> the server.
>>
>> One bit of information (support-yes-or-no) just isn't sufficient,
>> IMHO.
> 
> I believe you're trying to recover some determinism because of the 
> non-determinism I've introduced.

   No. I'm trying to detect an arbitrarily-large class of implementation
problems which may pop up.

   Granted, there's nothing to _do_ about them except recognize that
_somebody_ isn't speaking the protocol we specify; but for something
this radical, that's important information. :^(

> If so, I strongly believe that it's better to lessen the original
> non-determinism (e.g. by a larger magic number), rather than to add
> more message exchanges.

   (I don't see any additional "message exchange" here: like any
checksum, discarding packets which fail the checksum is the default
behavior.)

> If both achieve the same higher level of determinism, I'd much rather 
> use the one that avoids adding more branches to the protocol logic.

   As I said, that's not my aim.
 
>>> So it seems redundant for the server to feedback yet another
>>> confirmation via a checksum of all the extra options requested.
>>
>> Redundancy is your friend when complexity multiplies.
> 
> I believe the opposite is true. If you provide two different ways to 
> say the same thing, you create more complexity - to check they are 
> both saying the same thing. And if they are not, you have to decide 
> which one not to believe. This makes the spec and the code more complex.

   This isn't two ways to say the same thing: it's just a sanity check
to see if I should trust what you're saying at all. Once implemenations
settle down (ROTFL), the checksum will never fail.

>...
>>>> IMHO, the SYN sender should never use SYN-U unless extra option
>>>> space in the SYN is needed; and it's probably better to never use
>>>> SYN-U for connections where latency of setup is the over-riding factor.
>>>> But YMMV. I wonder whether such overlap is worth the trouble to try
>>>> to design into the protocol.
> 
> You're allowed your humble opinion. However, if you analyse the 
> SYNOPSIS protocol, you will conclude with absolute certainty that the 
> upgraded SYNOPSIS connection has no latency cost. So if a SYN-U gets 
> options through middleboxes, I predict it will be used whether or not 
> the extra space is needed.

   This issue is partly Overcome-By-Events, since Bob is working on a
version of syn-op-sis to cover _every_ packet in a TCP connection. I
will wait to read it...

>>> In the syn-op-sis spec there is a choice between two variants of the
>>> protocol (I recommend the choice can be made by implementers, not the
>>> IETF).
>>
>> This is a dangerous idea. Experimental results get hopelessly cloudy
>> when implementations are _fundamentally_ different...
> 
> I've put forward two pairs of variants. For the first pair of 
> variants, I have asked the IETF to decide between them (so I put the 
> one I least recommend in an Appendix).

   I'm not sure we all feel competent to make that choice... :^(

> But for the other pair of variants, I realised that the choice of
> variants can be left to the implementer, so I put it in the body
> (Section 6).

   (This really does complicate evaluation of the Experiment...)

> I didn't come to these conclusions without a lot of thought (whereas 
> up to draft-01 I hadn't fully thought this through)...
> 
> The only difference in the section 6 variant is the SYN-L. It became 
> clear to me that this is not a fundamental difference when I realised 
> that a middlebox could reduce the SYN-L to a SYN and it would turn 
> the protocol into the other variant. So the rest of the protocol is 
> identical.
> 
> The reason for allowing either at run-time is that the SYN-L variant 
> is more likely to be preferred after most servers have been upgraded, 
> but not at the start of deployment (explained in the Appendix linked below).

   That sounds like looking too far ahead. During an Experimental period,
rather few servers will be updated.

>>> The choice I've recommended removes any risk of extra latency
>>> on the upgraded connection. I've included a discussion of the
>>> tradeoff between them in Appendix B.1:
>>> 
>> <http://tools.ietf.org/html/draft-briscoe-tcpm-syn-op-sis-02#appendix-B.1>

   Interesting reading... But I'd prefer keeping the Experiment simple.

--
John Leslie <[e-mail]>