Picking up just this topic ... > "Black, David" <[email protected]> writes: > > > Hi David, > > > > This looks good, although I think this "SHOULD" requirement ought to be a > "MUST": > > > >> > If a host sends a SYN-only SYN+ENO segment bearing data and > >> > subsequently receives a SYN-ACK segment without an ENO option, that > >> > host SHOULD reset the connection even if the SYN-ACK segment does not > >> > acknowledge the SYN data. The issue is that unacknowledged data may > >> > nonetheless have been cached by the receiver; later retransmissions > >> > intended to supersede this unacknowledged data could fail to do so if > >> > the receiver gives precedence to the cached original data. > > > > and I would clearly characterize the following as suggestions for future > > work: > > > >> > Connection resets are potentially avoidable if SYN data caching is > >> > empirically found not to occur, or in response to an API command (for > >> > cases where a higher-layer integrity check would anyway terminate a > >> > garbled connection). > > > > This leaves specification of circumstances in which it's ok not to reset the > > connection to a future draft that explains why that's ok. > > I'm not sure I understand your suggestion. Wouldn't changing the SHOULD > to a MUST preclude the future work you are suggesting?
No, a future experimental (or standards track) RFC could revise that MUST. > I'm hoping to > reserve MUST for things that prevent future TEPs from conflicting with > one another or with TFO, not to prevent a future TEP from shooting > itself in the foot. Shouldn't we decide whether or not it's okay to > violate this recommendation if and when somebody proposes a TEP that > violates this rule (presumably armed with a giant measurement study)? It's fine to encourage future work and observe that the results could change the MUST in the future, but this distinction between conflicts and self-damage appears to be false - the problem occurs on a system that does not implement TCP-ENO or whatever TEP is being used, so something else's "foot" is getting "shot" ;-). Bottom line - IMHO, the current risks with delivery of unacknowledged cached data by non-ENO implementations (IMHO) justify a "MUST" for connection reset that ensures discard of data sent in an initial SYN-only packet. Such a "MUST" is not permanent (particularly in an experimental RFC) - it can be changed in the future by another RFC. Thanks, --David _______________________________________________ Tcpinc mailing list [email protected] https://www.ietf.org/mailman/listinfo/tcpinc
