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

[Joe Touch <[e-mail]>]

On 9/30/2014 7:45 AM, Bob Briscoe wrote:
> Joe & John,
> 
> At 19:11 29/09/2014, Joe Touch wrote:
> 
> 
>> 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*
> 
> As you know, syn-op-sis is designed so the client detects a legacy
> SYN/ACK and terminates that connection.

By the time the client receives the SYN/ACK, the legacy server would
have already forwarded FTO data to the user.

> The reason for requiring a syn-op-sis client to only ever locate TFO
> beyond the Data Offset in a SYN with extra options is precisely so that
> it will never use TFO to ask a legacy server to pass the payload to the
> app at the same time as it is placing (other) options in the payload.

Ahh - I see.

> And the wording in the draft generalises this to any future option that
> might cause a server to pass payload to the app during the 3WHS, not
> just TFO.

The problem is that you can't necessarily make assertions about options
that already exist, and this might complicate TCP option processing --
you need to enforce it on both client and server, and legacy receivers
can't know that this is a problem.

>> >> - upgraded servers will know where to find it
>> >>
>> >> Except to make parsing more complex, what is the perceived benefit of
>> >> using trailer-based signalling?
> 
> The fact that you (Joe) are asking the same question that I've already
> answered (on the list and in the draft) implies you don't accept the
> answer. But unless I can understand what you don't accept about the
> answer, I can only answer it the same way as I already have. However, I
> will try to spell it out more fully...
> 
> a) Ultimately, locating options as a trailer is not intrinsic to
> syn-op-sis. At this pre-implementation stage, a quick edit to the draft
> could locate them straight after the Data Offset.
> 
> b) However, as the initial proposition, I have located the options as a
> trailer, because middleboxes exist that look at the dest port, and they
> assume that the app-layer protocol is that associated with the port (eg.
> http if the port is 80). [Acting on this assumption violates layering,
> but I'll come to that.]
> 
> Then they parse the first X bytes of the payload, where the choice of X
> depends on the expect protocol and how much they can do at line rate.
...

I am skeptical that middleboxes parse SYN payloads, but even if they did
this might still not work. It depends on the size of the segment and the
size of the extension option space.

> * Locating extra options beyond the Data Offset (whether before or after
> the payload) provides a distinction between middlebox and destination
> options for the future.

That's necessary because the DO field is limited anyway.

> * Locating extra options after the payload is to avoid certain classes
> of existing muddleboxes, but with no intention to outwit meddleboxes
> (spelled out below).
...
>> >    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...
> 
> That's why I'm happy to evolve to a position where the current TCP
> options are intended for middleboxes, and it's at least acceptable if
> extra 'destination' options are 'harder-to-find'.

All TCP options are "destination" options.

However, the nature of dual-SYN requires that certain options always
come after the extension (as above) - but that also means it might
interfere with this partitioning by option type.

E.g., I would not be surprised at all to see TFO be of particular
interest to middleboxes - esp. to support load balancing while
supporting TFO.

>> 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'm not sure why the sender has any constraint on the order in which it
> serialises a segment. Surely it can construct the segment in memory in
> any order, then serialise it?

It can, but I don't understand the need to support more esoteric
middleboxes (including those I still consider meddlers) but not the
typical case where headers are built then data is added (or headers are
built in one place, data in the other, and the two combined).

Putting trailing options into that mix complicates lots of
implementations - and can be difficult to support in offload engines,
depending on how they handle buffers.

> John and Joe, I'm actually unclear what the context is for this part of
> the conversation. As a general point, it's not healthy to have email
> conversations where all the participants start with the words, "I
> haven't properly read the draft but...", then proceed to say there are
> probably problems, and then try to solve those probable problems.

I didn't start my email with that statement.
...

> It would be more useful for participants to trust that the author(s) of
> a draft wrote it because they have a solution, and they have taken some
> care to write it up carefully. Then it would be useful to hear critique
> (or praise) if there are problems with the draft (or not).

I disagree; it's useful to post directed questions and have direct
answers. Not everyone wants to try to infer intent from pages of text.

...
>> >    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.
> 
> Wrong. It is easy to solve for dual-SYN as explained in the draft (and
> above). As long as TFO is after the Data Offset, a legacy server won't
> pass the payload to the app during the 3WHS.

Agreed. As long as TFO is after the DO.

Joe