Re: [tcpinc] TCP's treatment of data in SYN packets

[David Mazieres <[e-mail]>]

Joe Touch <[e-mail]> writes:

> FWIW, IMO the best wording would:
>
> - start with the simplest case, i.e., NOT trying to optimize EDO to use
> SYN data
>
> - present the use of SYN data with EDO as an optimization
>         that optimization might be a MAY or SHOULD, but not a MUST
>
> Otherwise, you're needlessly complicating your spec for an optimization.

I'm not sure I follow.  The issue here is about application data that
needs to be decrypted, acked, and delivered in order.  EDO would seem to
be a poor fit for such data, particularly since TFO is already doing the
heavy lifting of normalizing the use of data in SYN segments.  That's
not to say ENO TEPs couldn't significantly benefit from EDO,
particularly if EDO is later extended to grow SYN segment options, but I
think the obvious application for that is early exchange of DH
parameters to optimize away the fourth flow in protocols like tcpcrypt,
and NOT any kind of TFO-like immediate data exchange.  We've already
implicitly addressed EDO by the suboption length byte and the fact that
you can repeat TEP suboptions if you need more than 32 bytes for a
non-final suboption.

More to the point, ENO is kind of a meta-specification, so we aren't
trying to optimize anything so much as to prevent chaos should TEPs
later want to employ optimizations.  To do so, we have to require data
to be ignored in a bunch of cases, otherwise future TEPs risk running
into weird problems with ENO-compliant hosts.

Also, to clarify, the bulk of the document is about the simplest case,
but the wording I proposed if for a subsection specifically addressing
what to do if you receive SYN data--namely ignore it and don't ACK it in
a bunch of potentially problematic cases.

If this isn't clear, I can post a new draft so that everyone can see the
proposed language in context, and we can take it from there.

David