On Thu, Jul 28, 2016 at 4:16 PM, David Mazieres < [email protected]> wrote:
> Thanks for this explanation. This matches my understanding, and raises > a subtle point because of the elimination of the application-aware > mandatory bit on the wire. Suppose you are in the following situation: > > * Host A and host B have previously established a bunch of TCP-ENO > sessions successfully, so believe the network path is clear and so > forth. > > * The application on host A suddenly sets the mandatory > application-aware mode, and host B is not application aware. > > * Host A uses a TEP that allows for SYN data, and in fact tries to use > SYN data on the next connection. > > * Host B acks the SYN data, because the SYN TEP is also the negotiated > TEP. > > * Host A disables TCP-ENO because host B was not application aware, so > the third leg of the handshake does not include an ENO option. > > At this point host B would have to discard the data, since it includes > ciphertext. If the data were a Diffie-Hellman parameter this might be > okay, though a redefinition of TCP's behavior since the data was ACKed. > I'm hesitant to redefine TCP's behavior in a way that does not closely > hue to other studied modifications such as TFO. > > In particular, TFO suggests required buffering is not the best behavior. > In fact, I would imagine in the short term SYN data is most useful for > cases like session resumption, where you really want the data directly > delivered to the application (since it's cryptographically authenticated > anyway) and not buffered. This is a modification of TCP I feel > comfortable with because TFO has essentially already vetted this model. > > One possible solution is to say that you cannot send data in the SYN > segment if you set the application-aware mandatory bit. Another > possible solution is to convey the application-aware mandatory bit by > going back to two a bits, the way we had a few drafts ago. > If box B sends back an ENO option, we know it's ENO aware, so we can choose the behavior here; we just need to make sure it's consistent and knowable by both endpoints. Why can't the semantics here be that B throws away the SYN data if it disagrees with A on app awareness? Are there situations where the two endpoints could disagree on this determination? If this works, then in the steady state (both endpoints are either app-aware or not) clients will be able to send SYN data to known ENO-aware servers, while in the rollout case (A and B don't agree on app awareness) SYN data will be thrown away by B and known by A to have been thrown away. I still don't have a good feel for what folks like Joe are recommending re: dealing with a B that doesn't understand ENO. If B is suddenly not ENO-aware, by the spec it could deliver garbage data to the application upon completion of the 3WHS; is this okay under an assumption that B should *not* suddenly be unable to understand ENO, or do we need explicit signaling from a prior connection to the same IP saying "SYN data is okay upon resumption", or is even that not good enough? A lot of this would be resolved if we updated TCP to say that a server MUST not ACK, buffer, or deliver SYN data unless this behavior is overridden by some negotiated extension (like TFO or ENO), in which case the treatment of such data is extension-specific. The ship has probably sailed on that one, but it's interesting that this is essentially what 4987 states, as I posted at the top of the thread: q( If data accompanies the SYN segment, then this data is not acknowledged or stored by the receiver, and will require retransmission. ) Kyle
_______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
