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

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 2 Oct 2014 15:28:50 +0000

>    I believe that much deserves to be settled _before_ tcpm-fastopen
> is published as an RFC. (NB that document currently has been approved
> for publication, but is waiting on a Point-Raised writeup.)

I don't think that this (good!) discussion should affect draft-ietf-tcpm-fastopen. We explicitly decided that the existing TCP fast open spec shall be experimental.

I think this kind of discussion can be sorted out if / once we move fast open to PS. This almost certainly won't happen within quite a number of IETF meetings. Thus, we probably have enough time to fully understand and discuss the interaction with SYN option extension solutions.

Michael

---

From: John Leslie <[email-masked]>
Date: Sun, 5 Oct 2014 20:38:01 -0400

Bob Briscoe <[email-masked]> 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 <[email-masked]> wrote:
>>> At 15:50 26/09/2014, John Leslie wrote:
>>>> Bob Briscoe <[email-masked]> 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 <[email-masked]>

---

From: Bob Briscoe <[email-masked]>
Date: Tue, 7 Oct 2014 11:30:00 +0100

John,

At 01:38 06/10/2014, John Leslie wrote:
[snip]
>    Interesting reading... But I'd prefer keeping the Experiment simple.

OK, you've helped me realise that it isn't necessary for a client to 
/send/ a SYN-L for the experiment. But experimental servers have to 
implement code in case they /receive/ it, otherwise the transition 
from experiment to production will be messy.

That requires a one-line addition to an experimental server. And in 
the spec it requires two normative sentences in the body, and an 
explanation for why they're there in an appendix. The second sentence 
is to give notice to middleboxes to expect to see a SYN-L in the 
future (e.g. intrusion detection systems).

This shows that it's always worth looking 'too far' ahead. 
Traditionally, we've been bad at 'forward compatibility'.

It's possible I will be able to get the promised rev of syn-op-sis 
out today, as long as I don't get pulled off onto something else.

Bob

________________________________________________________________
Bob Briscoe,                                                  BT