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

[Bob Briscoe <[e-mail]>]

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.

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.

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.

> >>
> >> - 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. If the payload does not start with the expected app-layer 
commands, what they do next depends on the box function:
* If it's an intrusion detection system, it will probably drop the packet.
* If it's a app-layer filter, it will probably drop the packet (e.g. 
a Web filter is looking for the requested Web page to determine 
whether to block it, and it becomes suspicious when it's not even http).
* If it's a performance accelerator, it will probably forward the 
packet without being able to use any of its app-specific acceleration 
capabilities, because it doesn't recognise the app-layer protocol.

I would be very happy if experiments showed such middleboxes are a 
corner-case, but I suspect they are not.

I know these boxes violate layering and we do not have to dance to 
their tune. However, my goal is simple:
  There is no point in providing extra option space in a SYN if it 
does not get delivered.

There is a tradeoff between the probability of getting delivered and 
the complexity introduced to the protocol.

My simple view is that I would rather do (limited) extra processing 
on all packets so that a greater proportion get delivered. What use 
is it if an implementation doesn't work but it's efficient?

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

* Locating extra options beyond the Data Offset (whether before or 
after the payload) provides a distinction between middlebox and 
destination options for the future.
* Locating extra options after the payload is to avoid certain 
classes of existing muddleboxes, but with no intention to outwit 
meddleboxes (spelled out below).

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

Noted.


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

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

Correct, John (in the case of an upgraded receiving endpoint).

> >
> >    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 think/hope you have switched to talking about the processing order 
on the sender here, because of the word 'puts'.

I don't understand tho what you (John) mean by "extended-options 
comes along and puts its data". What do you mean by 'data' in this 
case? User-data related to an extended option? Or the option fields themselves?


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

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.

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

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.

>It's one that the OOB method is not susceptible to, though.

Correct.


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

It would not. As above.

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

It would not. As above.

In summary, TFO is not a problem for all three dual-segment 
approaches on the table:
- SYN-EOS OOB
- SYN-EOS DS
- syn-op-sis.


Bob


>Joe

________________________________________________________________
Bob Briscoe,                                                  BT