Re: [tcpinc] AD review of tcp-eno

[Joe Touch <[e-mail]>]

FWIW:


On 7/27/2017 8:40 AM, Joe Touch wrote:
> ...
>>>>> 2) I’m wondering if it would make sense to specify at the beginning of section 4.7 another requirement that TEPs SHOULD only specify the use of SYN data if there is some a-priori knowledge that the other end is likely to support tcp-eno and the tep (e.g. due to previous successful connections aka session resumption, or application knowledge).
>>> That section does not appear to address the case where non-user data in
>>> the SYN is received by a legacy receiver, either because of first
>>> contact or in contacting a host that has changed configuration since
>>> last contact. In such cases, there is no way to support transparent
>>> fallback as required by RFC 1122 -- which is why it is avoided at all
>>> costs. AFAICT, this optimization is too hazardous to include at all.
>> It does. The initiator must reset the connection in this case.
> I would assume then that NO TCP connection is possible to that endpoint
> - i.e., by aborting the connection, you're saying that this endpoint is
> not reachable because it's "ENO or nothing".
>
> If so, that needs to be made very clear - especially that it is not
> appropriate for the TCP layer to try another connection without ENO
> (i.e., transparent fallback NEVER involves multiple connection attempts
> - otherwise you're violating RFC1122).

The text does address this case, but still a bit too vague IMO. I'd
appreciate an explicit statement highlighting interaction with legacy
receivers, including a note that even a previously-visited ENO node
might be legacy upon next contact, and stating that the connection abort
MUST NOT include an automatic subsequent attempt at fallback, e.g.,
because BOTH this violates the nature of ENO (once the client wants ENO,
it's ENO-or-nothing) *and* because automatic fallback would violate TCP
semantics.

Joe