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

[Andrew Yourtchenko <[e-mail]>]

On Thu, 25 Sep 2014, Joe Touch wrote:

>
>
> 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.

Thanks for the clarification!

>
> 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.

Makes sense, if both are valid SYNs for the legacy endpoint, indeed.

>
>> (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.

They're used quite frequently outside of HTTP
(http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/dns-srv-record-use-by-clients.html)
though the "outside of HTTP" part makes it quite infrequent.

OTOH, the SRV record has just priority,weight,port,target-name - there is 
no space for the hint as such. OTOH maybe a new record type that could be 
returned in "additional" field within the reply?

Regardless, the DNS "hint"'s presence could change the game quite a lot - 
if you know that the remote end is supporting the new cool extension, you 
you might want to make a leap of faith and give it a chance first, with 
the quick enough fallback to make the impact minimal yet avoid two SYNs if 
possible.

>
> ...
>> 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.

Exactly. The connecting side may decide it makes sense if it knows upfront 
from either the hint in DNS, or its own cache of previous connections to 
that host (which may not be valid, BTW - because the network inbetween 
might have changed)

>
> 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)

It's a tradeoff.

two-SYN methods stall one of the connections during the 
transition period at initiator's discretion (with maybe using DNS hints 
or its local cache to decide which one to stall and the protocol type to 
decide for how long to stall), *or* cause two SYNs race which is not very 
nice. Assuming the stall delay is X, the session establishment time in the 
worst case is ~(1.5RTT+X)

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.

If the client then proceeds as if the connection was legacy, the session 
establishment time is ~(1.5RTT+Y) - so, better than two-SYNs.

But if the client decides to retransmit the OOB (the worse performing 
case of the, the overall connection establishment time will be 
~(2.5*RTT+Y). And there'd need to be logic to still fallback to the legacy 
behavior if the (Second, third?) OOB packet gets dropped.

If the above estimates make sense, then it's a tough call to make 
which one is better without trying in the wild, IMHO.

--a