Kyle Rose <[email protected]> writes: > This is really good information: thanks! I think if tcpinc decides to > pursue early data, we'll want to learn as much as possible from your > experience.
So just to scope what we had in mind, "pursue early data" sounds a bit aggressive. What I think we had in mind is just saying something about what receivers MUST do when receiving a SYN segment with data, not encouraging people to do that. Since TFO will eventually cause people to address these middlebox issues, it would be nice to avoid creating a second round of problems where TCP-ENO implementations also crash or do weird stuff. And it would also be nice if TCP-ENO didn't disable this possible optimization. What I had in mind was something along the lines of saying that the last TEP suboption in host A's SYN segment is the SYN TEP, and that host B MUST ignore and MUST NOT ACK any data in SYN segments unless the negotiated TEP is the SYN TEP and that TEP explicitly defines the use of data in SYN segments. Furthermore, SYN data MUST be discarded in the event that TCP-ENO is disabled, even when such data has already been ACKed. TEPs MAY define the use of data in SYN segments for when they are the SYN TEP, but SHOULD limit such usage to cases in which it is known that the passive opener and network path both support ENO. David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
