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 12:21 PM, Andrew Yourtchenko wrote:
> ...
>>>> 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.
> ...
>> 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?
>
> SRV records sometimes define additional parameters in the TXT records.
> See here:
> www.iana.org/assignments/service-names-port-numbers/
>
> (search for TXT)

geez! Thanks for this link. I thought the uses of TXT beyond "descriptive 
text" were always very much frowned upon.

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

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

>
>> 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.
>
> The client need not wait for a RTT to retransmit the OOB; multiple OOBs
> have no impact on the server. Clients can send an OOB before and after
> the SYN, and if the OOB gets there and is cached it wins; if the OOB
> arrives after, the delay is just the arrival delay.

See above on the definition of the worst case - the OOB spec does not 
appear to be clear. Maybe it's better to leave more ambiguity so this can 
be experimented with, but this this worst case was certainly at least to 
me one of the big differences between the 2-SYN and OOB approaches.

--a


>
> Joe
>