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

[John Leslie <[e-mail]>]

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.

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

> *- 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. This probably deserves
mention in any dual-SYN proposal.

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

--
John Leslie <[e-mail]>