Re: [tcpinc] AD review of tcp-eno

[Joe Touch <[e-mail]>]

Hi, Mirja,

On 7/27/2017 8:21 AM, Mirja Kuehlewind (IETF) wrote:
> Hi Joe,
>
> thanks for your feedback. See comments inline.
>
>> Am 27.07.2017 um 16:25 schrieb Joe Touch <[e-mail]>:
>>
>> On 7/27/2017 6:14 AM, Mirja Kuehlewind (IETF) wrote:
>>> ...
>>>> I’m afraid we need a new revision before IETF Last Call because the RFC should only specify the actually TCP option and not the experimental one. So you can simply remove the experimental one in Figure 1, 2 and 3 (as well as sec 4.8) and only note in the IANA section that this experimental assignment also exists, as it is already done.
>> First, as an Experimental RFC, I don't think it would be appropriate to
>> assign a codepoint that requires a standards-track doc.
> We have actually assigned quite a couple of option numbers to experimental RFCs lately, given it is very common to go for experimental first in transport. 
I have raised concerns with this practice in other cases, so I'll raise
it here. The whole point of experimental is for these cases. The TCP
option space is littered with failed experiments, and should not be --
that is exactly what the mechanism in RFC6994 is intended for.

> As this work is chartered for experimental, we will go with IESG approval in this case, however, maybe we should consider to change the policy to "IESG Approval or RFC Required“ instead.
The current requirement is "IESG approval or standards-track RFC
required" - an intentionally high bar. There's no good reason to lower
that bar, esp. for small codepoint spaces in core Internet protocols.

>> Second, regardless of whether the IESG decides to override that
>> requirement, this document needs to address how to handle packets with
>> the ExID values that have already been assigned if they are considered
>> to be part of the transition plan (though it would be better to describe
>> a transition plan). Per RFC6994, the authors do need to address this
>> issue, especially indicating that connections should *not* include both
>> variants in the same segment.
> That’s right. I though RFC6994 would make a general recommendation here. But I guess it’s anyway good to add one sentence that implementations that following this specification should actually not respond to the experimental option. Thanks for noting.
Actually, this RFC ought to clearly indicate this assignment and have
normative language for addressing segments with it and the IANA
instructions ought to indicate that the assignment should point to this
RFC. Otherwise we lose a documentation trail.

>
>> Finally, IMO, if a TCP option codepoint is assigned, I strongly
>> recommend not poisoning the codepoint space with a "fresh" assignment,
>> nor should the developers be rewarded for squatting on a value. The only
>> appropriate solution IMO, in that case, would be to assign this option
>> to a codepoint already squatted **by another party**. In that case,
>> their deployment would appropriately suffer from the impact of squatting.
> While I know the problems with squatting that we have, I don’t think is a suitable option to enable good deployment for this or any new IETF protocols that we invested a lot of time in. 
Actually, I think this is EXACTLY the kind of option to do this - those
who create the problem of squatting should experience the impact of
their actions.

> I though we had this discussion already and concluded that the best viable option for this case is the number that they already squatted on. 
I don't know if we did, but I don't think that's appropriate - it
encourages squatting by rewarding it.
>>>> Other minor comments:
>> ...
>>>> 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).

Joe