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

[Joe Touch <[e-mail]>]

On 9/25/2014 3:48 PM, Andrew Yourtchenko wrote:
> On Thu, 25 Sep 2014, Joe Touch wrote:
...
>>> OOB method has a permanent decision to stall the connection if the
>>> upgraded server receives SYN-EOS OOB but no OOB segment (say, it's being
>>> blocked by the middleboxes?), "after a certain time". This time
>>> supposedly should be much shorter than the stall in the two-SYN case,
>>> ideally a function of jitter on the path, let's call it Y.
>>
>> That can be zero if the OOB arrives first or during the processing of
>> the SYN.
> 
> Sure. It's not about reordering. It's about the worst case scenario.
> 
> Best case scenarios "when everything works" both OOB and 2-SYNs are
> ~equivalent, the mild failure cases are nicer with OOB iff Y is smaller
> than X. OOB has the additional advantage of not consuming one more
> connection slot for a short period of time on the middleboxes (and the
> per-flow processing capacity).

Also on legacy servers it opens only one connection.

>>> If the client then proceeds as if the connection was legacy, the session
>>> establishment time is ~(1.5RTT+Y) - so, better than two-SYNs.
>>
>> A legacy client wouldn't wait for the jitter - they would ignore the
>> SYN-EOS flag in the SYN, and wouldn't know to wait. The OOB segment
>> would get silently dropped if/when it arrives.
> 
> We seem to somehow miscommunicate the case description. Sorry, it's late
> here, maybe mea culpa.
> 
> The case under discussion, which is the worst case scenario is: new
> client talking to new server with an evilbox in the middle dropping the
> OOB 100% of the time.

That's one reason why we need to experiment with OOB packets; I don't
know what will happen, except in the case when OOB comes too early
before the SYN through a NAT.

However, dual-SYN has the problem of potentially going to different
servers or through different NATs and of opening multiple connections on
legacy servers (thus impacting service rate).

I wouldn't be surprised if the best path forward were to document each
as a separate experiment and try them both.

Joe