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

[Joe Touch <[e-mail]>]

On 9/25/2014 9:41 AM, Andrew Yourtchenko wrote:
> Bob, Joe, all,
> 
> some comments below, maybe with some obvious questions as I did not
> follow the latest discussions very closely.
> 
> On Thu, 25 Sep 2014, Bob Briscoe wrote:
> 
>> Joe,
>>
>> At 23:25 24/09/2014, Joe Touch wrote:
>>> Hi, Bob (et al.),
>>>
>>> It's good to have a more detailed description of the proposal.
>>>
>>> I still find a dual-SYN solution untenable, though, as it has been for
>>> other upgrade paths in the past (e.g., IPv6).
>>
>> That's why I prefer syn-op-sis because it only uses 2 SYNs for
>> transition.
> 
> Both syn-op-sis and tcp-syn-ext-opt talk about using
> different port pairs 

tcp-syn-ext-opt describes two different approaches:

	SYN-EOS-OOB	uses one port pair, sends only one SYN

	SYN-EOS-DS	uses two port pairs

the DS variant is very similar to the one in syn-op-sis; both are Bob's
suggestion. Mine was SYN-EOS-OOB.

Bob - let me know if its useful to retain SYN-EOS-DS or if you want to
replace it with syn-op-sis.

> - is this due to the explosion with the number of
> possibilities for the three-way handshake recovery ?

Two ports are used only when two SYNs are sent, largely to avoid the
second SYN from affecting the progress of the first that arrives at a
legacy endpoint.

> (Of course the application will anyway see only 1 file descriptor, which
> will assume the identity of the connection that succeeds, right ?)

Yes.

>> I've included a new section on ways to use only 1 SYN during
>> transition (building a white-list) and ultimately moving to 1 SYN in
>> the future, only falling back to the legacy SYN in series rather than
>> parallel if you hit a legacy listener.
> 
> The fundamental difference between the transition to the extended option
> space and IPv4->IPv6 transition is the absence of the DNS to signal the
> capabilities of the endpoint before the connection even starts - if the
> target host has A&AAAA you only have to deal with the failures on the
> path, while if the target host does not have AAAA record, it's worthless
> to try IPv6.
> 
> OTOH, when attempt to negotiate the extended option space, you do not
> have any hints about the remote end - besides maybe past memory.

You could have similar hints in SRV records, though those are used much
less frequently.

...
> In today's conditions, a simple 300ms headstart for IPv6 if AAAA is
> advertised might be sufficient, as the subpar IPv6 connectivity
> disappears, and more of the corner cases get into play for RTTs.
> 
> So, depending on how much of a drop rate we'd expect for a "new" SYN
> across the variety of network scenarios, the simpler approach of just
> using 300ms delay could be reasonable due to its simplicity - an
> experiment could show.

Sure, but it also has creates delay on either the legacy or upgraded
connection - depending on which SYN is stalled.

That's the advantage of the OOB method - there's no need to insert a
stall on the sending side (an upgraded receiver might cache OOBs that
arrive briefly before SYNs to avoid the need for an additional exchange)

>> The other two in tcp-syn-ext-opt have to be 2-SYN for ever.

They're two segments forever. Only one is two SYNs.

Joe