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

[Joe Touch <[e-mail]>]

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)

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

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

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

Joe