Hello,
I have read through the TCP-ENO draft and have a few comments:
First, am wondering whether there might be an issue when the third ACK gets
lost.
Specifically, the draft says that a host MUST disable ENO if the following
condition is met:
4. The first ACK segment received by a host does not contain an ENO
option.
So, if this ACK gets lost, and the client goes on with sending (encrypted)
data, the server won't be able to know whether ENO has been successfully
negotiated or not and how to interpret the data.
To overcome this, one possible way would be to include the ENO-option in every
data-segment that a host is sending after the 3-way handshake until successful
use of ENO has been confirmed by the receiver.
But even then, there might be a middlebox that removes the ENO-option from
non-SYN segments (assuming that we want to support such kind of middleboxes).
The sender will thus send encrypted data with the ENO-option. The receiver
receives this encrypted data without the ENO-option (due to the middlebox
stripping the option) and thus will assume that the data is unencrypted. (for
the background, this kind of behavior is the reason why MPTCP makes sure to
only send in-order data in the first few segments, until middlebox-support has
been confirmed as it allows to fallback to regular TCP)
This kind of means that we would need to do a 4-way handshake where data can
only be sent after it has been confirmed on non-SYN segments that ENO is
enabled. Maybe there is a better solution to it?
Second, there are loadbalancers out there (used by baidu.com
<http://baidu.com/> in particular) that echo unknown TCP options. As far as I
can tell, TCP-ENO won't be able to handle this situation gracefully, as an
active opener will interpret the ECHO'd option as valid. The P-bit seems to
allow to resolve this situation as the client would receive a TCP-ENO option
with the P-bit set on a SYN/ACK segment. But, the P-bit is currently not part
of the option thus I think it would be good to include it.
Cheers,
Christoph_______________________________________________
Tcpinc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tcpinc
