On 2/22/2017 1:58 PM, David Mazieres wrote:
Wesley Eddy <w...@mti-systems.com> writes:
1) edge cases where you're communicating with non-ENO hosts, that do not
discard data on SYNs (for whatever reason), and may pollute the data
stream delivered to the application, breaking the goals of TCPINC to
work without impacting the application's TCP mapping
2) cases where other TCP extensions (perhaps yet to-be-defined) do
something in conflict with that data
Can you make concrete suggestions for wording changes? In particular,
we intended to address the points you raised with the following language
of section 4.7:
1)
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 MUST reset the connection even if the SYN-ACK segment
does not acknowledge the SYN data...
Saying "reset the connection" is interesting to me, because technically
there is not yet any connection (there are TCBs at each side, but
neither has entered ESTABLISHED state). The reset that's sent should
probably *not* acknowledge any data that may have been on the SYN-ACK,
which seems important to state. That way, if some application's
transaction erroneously started due to data on the SYN, any response
piggybacking the SYN-ACK would not be acknowledged, and the RST should
cause the application transaction to fail.
To avoid unexpected connection resets, ENO implementations MUST
disable the use of data in SYN-only segments by default.
In my opinion, it might be better to disable the use of data in SYN-only
segments unless the peer's ENO capability is already known through some
means (e.g. TCB cache from prior connections).
_______________________________________________
Tcpinc mailing list
Tcpinc@ietf.org
https://www.ietf.org/mailman/listinfo/tcpinc
