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

[Joe Touch <[e-mail]>]

On 9/29/2014 9:58 AM, John Leslie wrote:
> Joe Touch <[e-mail]> wrote:
>> On 9/26/2014 12:53 PM, John Leslie wrote:
>>> Bob Briscoe <[e-mail]> wrote:
>>>> " If an upgraded TCP client includes the TCP Fast Open option
>>>> " [I-D.ietf-tcpm-fastopen] in the SYN, it MUST be placed with the extra
>>>> " TCP options after the end of the payload.
>>>
>>> Indeed, that is a good way to ensure that the SYN receiver is aware
>>> of the sender's intent to place something _after_ the data intended to
>>> be passed to the application.
>>
>> I'd like to understand the logic behind this claim.
> 
>    Good!
> 
>> Regardless of where signalling information is placed:
>>
>> - legacy servers will (irrevocably) accept it as
>> application data; the only way to undo it is to
>> terminate the connection*
>>
>> - upgraded servers will know where to find it
>>
>> Except to make parsing more complex, what is the perceived benefit of
>> using trailer-based signalling?
> 
>    Bob, I believe, thinks he can outwit meddleboxes. I'll let him make
> that case.
> 
>    Myself, I see it a a way to coexist with things to come.
> 
>    Joe, I suspect, is thinking how to do this in hardware.

Not specifically. IMO, might create another opportunity to get things
wrong because it's now how we currently process options.

>    Indeed, to a middlebox, harder-to-find translates to "expensive",
> possibly prohibitively expensive. To an actual endpoint, the expense
> is bearable -- if you need to act on both anyway, it's a toss-up...
> 
>    But myself, I think in terms of how to coexist with future things
> like FastOpen. I believe we've got a better shot at ensuring that
> nothing _follows_ our extended options than ensuring that nothing
> precedes them.
> 
>    Repeating Bob's words:
>>
>>>> " If an upgraded TCP client includes the TCP Fast Open option
>>>> " [I-D.ietf-tcpm-fastopen] in the SYN, it MUST be placed with the extra
>>>> " TCP options after the end of the payload.
> 
> and recalling that extended options _can't_ be parsed until the inital
> TCP option invoking extended options is parsed, we see that the receiving
> endpoint _must_ know about the overlap of extended-options and fast-open.
> 
>    That brings us to the tussle of whether either _must_ play with the
> data the other wants to add. To me, the simplest case is that fast-open
> does its job first (hopefully someday to include a byte-count), while
> extended-options comes along and puts its data after fast-open's data
> (and anything else which may come along), trusting the receiver to
> remove it from anything to be passed to the application.

I'm not sure I understand this. User data can't be placed in (or removed
from) the segment until after all the options are handled anyway.

>    I am convinced we will see cases where both fast-open and extended-
> options need to be used.
> 
>    While this tussle could go either way, I prefer to place the
> complexity in extended-options.

It's clearly only the option processing that should ever care where the
options are...

>> *- TCP-FO is particularly dangerous when coupled with dual-SYN (DS)
>> variants when the connection uses a cookie from a previous connection;
>> non-DS FO servers can't prevent passing invalid data to the application
>> by terminating the connection when the SYN-ACK is received by the client.
> 
>    I had to read this twice to get Joe's point. :^(
> 
>    Dual-SYN solutions would be expected to place fast-open in both SYNs,
> probably with the same cookie. In the legacy case, nothing can prevent
> the payload being passed to the application long before the sender
> becomes aware of the state of the other SYN.

Right - the legacy case of FO + any dual-SYN approach has this problem.
It's one that the OOB method is not susceptible to, though.

>    (Obviously, if the legacy SYN is postponed long enough, this ceases
> to be a problem; but by then you've lost most of the latency advantage.)

That would happen only on a DS-capable server. I'm also thinking of the
legacy server case - which might not only open two TCP connections but
(with TFO) would send data to the user too early in the upgraded-SYN
case - and it's corrupt data because the server is interpreting the
extended option as user data.

Joe