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

[John Leslie <[e-mail]>]

Bob Briscoe <[e-mail]> wrote:
> At 15:50 26/09/2014, John Leslie wrote:
>>Bob Briscoe <[e-mail]> wrote:
>...
>>   I'd like to remind folks of two other drafts:
>>
>>- draft-ietf-tcpm-fastopen "allows data to be carried in the SYN" packet.
>>  Something like this is inevitable; and _will_ put application-layer
>>  data in the inital SYN (to reduce experienced latency).
> 
> This is referenced from both drafts.

   Yes. I felt a need to emphasize it...

> You have to be careful using fast open as well as putting TCP options 
> in the payload. I've written the following into 
> draft-briscoe-syn-op-sis, and a similar rule will be needed in 
> draft-touch-tcpm-tcp-syn-ext-opt:
> 
>" 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.

>" An upgraded TCP client MUST NOT place any TCP option in the TCP header
>" of a SYN that might cause a TCP server to pass user-data directly to
>" the application before the 3-way handshake completes.

   This is correct, if a bit hard for the reader to grok...

>>- draft-nishida-tcpm-apaws "can provide protection against old duplicates"
>>  without using timestamps. (Timestamps will eat up ten bytes in _every_
>>  packet.) This should reduce the demand for option space in the SYN.
> 
> Most certainly agree. See quoted text under the next point...
>... 
>> Hopefully I don't need to draw attention to draft-touch-tcpm-edo.
>> This seems to be moving towards consensus on how to increase the option
>> space on every packet _after_ the initial SYN.
>>
>> Thus, in most cases, for today's traffic there is little need to
>> worry about extending the option space in the initial SYN. There seems
>> to be plenty of time to experiment...
> 
> Not sure I'm so relaxed. Quoting
> <http://tools.ietf.org/html/draft-briscoe-tcpm-syn-op-sis-02#section-1.1>
> 
>" 1.1. Motivation for Adoption (to be removed before publication)

   (I think the point deserves to be made in the published RFC.)

>"   It is recognised that there could be potential for compressing
>"   together multiple options in order to mitigate the option space
>"   problem.  However, it seems inevitable that ultimately more option
>"   space will be needed, particularly given that many of the TCP options
>"   introduced recently consume large numbers of bits in order to provide
>"   sufficient information entropy, which is not amenable to compression.

   I agree on the ultimate need. But it will necessarily be postponed
until we finish Experimental status and move to Proposed Standard.

>"   Extension of TCP option space on a SYN requires support from both
>"   ends.  This means it will take many years before the facility is
>"   functional for most pairs of end-points.  Therefore, given the
>"   problem is already becoming pressing, a solution needs to start being
>"   deployed now.

   (No objection to that text.)

>> For any Experimental-status document, I recommend:
>>
>> - that the various on-the-wire formats be kept as similar as possible;
>>
>> - that any acknowledgment of extra option space in an initial SYN
>>   include a checksum or hash of the extra options to ensure that both
>>   ends have the same view of what options have been signaled;
> 
> Not convinced on this one. Each TCP option has its own way for the 
> 'server' to confirm whether it supports an option requested by the 
> client.

  And this one should also have its own way. I see so many things that
could get in the way that I _strongly_ recommend some checksum/hash.

> And support for the option to extend the option space is confirmed by
> the server.

   One bit of information (support-yes-or-no) just isn't sufficient,
IMHO.

> So it seems redundant for the server to feedback yet another
> confirmation via a checksum of all the extra options requested.

   Redundancy is your friend when complexity multiplies.

>> IMHO, Bob's SYN-U cases are best condensed into a single format
>> where the SYN sender explicitly notes the position in the payload to be
>> occupied by additional TCP options, and guarantees that no application-
>> layer data will follow these.
> 
> Good point about the guarantee.
> 
>> The receiving endpoint would search for the extra options whether or
>> not it found the SYN-U option in the initial SYN,

   (Did I write that?? I was thinking MAY...)

> This won't work. This would require every server to hold a list of 
> valid TCP options and their valid length fields. This list is large, 
> and the list of future options yet to be defined is even larger (and 
> obviously unknown).

   But that's exactly what you solve in you "non-deterministic" version.

>...
>> and reply including a checksum/hash of the options it found. (The
>> receiving endpoint MUST find some confirmation that these options
>> were intended, or _it_ bears the responsibility to reverse any
>> action on the extended options and pass the payload where it
>> otherwise would have gone.)
> 
> No need for all this - see above and see drafts.

   Your non-deterministic version does this with a magic-number. That
is an obvious weakness. I intended to draw attention to the issue --
not propose a particular solution.

   But obviously: if the SYN sender sends a SYN-U which the receiver
doesn't get because a meddlebox removed it, the sender can learn of
the problem when a returned checksum fails -- but the receiver won't
know of the problem until the sender aborts.

   The receiver might choose to delay sending fastopen data in every
case where no SYN-U was received -- or there are other possibilities.
Pick your poison...

>> I'm not sure this entire middlebox-transit idea is worth the trouble;
>> but it probably deserves to be an optional part of the experiment.
> 
> The reason I came up with syn-op-sis is to be able to be near-certain 
> that it will get through current middleboxes. I think the group will 
> find such near-certainty to be liberating, compared to the minefield 
> we currently have to tip-toe through.

   But it does add complexity. I won't pre-judge what balance of
complexity the WG may chooose.

> The only case I can think of where there could be a blockage is where 
> a split TCP connection holds back any payload on the SYN until the 
> 3WHS completes.

   ... which _will_ happen... :^(

>> The SYN-U sender MUST deal with the danger of its additional options
>> being passed to the application as data. For legacy receivers it can do
>> this by aborting before the end of the three-way handshake. But there
>> must be coordination with tcpm-fastopen to protect against such data
>> being passed to the application before the SYN-U sender can abort.
>> (This is not a trivial consideration!)
> 
> Altho certainly not a trivial consideration, it is trivial to be safe 
> against this - see the rule already in the syn-op-sis draft, quoted 
> above, which is careful to be specific about TFO, as well as 
> generalising to anything in the future that might be like TFO (e.g. 
> tcpcrypt uses the TCP payload for control messages).

   I expect fastopen to see widespread use -- and I expect it to be
programmed by different folks that program syn-op-sis. Our warning
label (IMHO) needs to be rather prominent...

>> The question of separating payload data to go to the application
>> from extended TCP options clearly requires action by the SYN receiver.
>> This is fairly simple if the SYN sender can ensure that _none_ of the
>> payload data should go to the application (and thus not use fastopen
>> at all): of course the connection must still be aborted if the SYN
>> receiver doesn't acknowledge separating out the extended options.
>>
>> IMHO, the SYN sender should never use SYN-U unless extra option
>> space in the SYN is needed; and it's probably better to never use
>> SYN-U for connections where latency of setup is the over-riding factor.
>> But YMMV. I wonder whether such overlap is worth the trouble to try
>> to design into the protocol.
> 
> In the syn-op-sis spec there is a choice between two variants of the 
> protocol (I recommend the choice can be made by implementers, not the 
> IETF).

   Hmm...

   This is a dangerous idea. Experimental results get hopelessly cloudy
when implementations are _fundamentally_ different...

> The choice I've recommended removes any risk of extra latency 
> on the upgraded connection. I've included a discussion of the 
> tradeoff between them in Appendix B.1:
> <http://tools.ietf.org/html/draft-briscoe-tcpm-syn-op-sis-02#appendix-B.1>
> 
> BTW, I spend most of my time these days working on a project to 
> remove latency from protocols.

   :^)

   (Can you spell ECN?)

--
John Leslie <[e-mail]>