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

[Bob Briscoe <[e-mail]>]

John,

At 01:38 06/10/2014, John Leslie wrote:
[snip]
> > 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.

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