Joe Touch <[email protected]> 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 _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
