Re: [tcpm] A possible simplification for AccECN servers

["Scheffenegger, Richard" <[e-mail]>]

Am 12.12.2019 um 17:37 schrieb Bob Briscoe:
> Richard,
>
> On 28/11/2019 11:34, Scheffenegger, Richard wrote:
>>
>> Hi,
>>
>> I support the new text that Bob has suggested to allow a AccECN server
>> to choose to not support RFC3168 ECN.
> Can you give reasons - I'm trying to understand what to do given
> conflicting preferences.

I think it is not unreasonable to leave the decision, if a particular
server chooses to not fall back to ECN, if an RFC3168 client asks for
ECN support, to the deployer of the server.

By itself, ECT0 can already be seen as a classifier (we've had this
discussion with L4S and ECT1). In this light, non-ECT vs ECT0 (or ECT1)
can end up in different queues. If the server operates in an environment
that doesn't lend itself to good interoperability with RFC3168 ECN, the
server might want to not run ECN at all with a RFC3168 client. Thus
preferring to operate in loss-only congestion feedback rather than a
potenial problematic ECN feedback.

While at the same time, it may want to utilize the full potential when
in a session with another AccECN client...


>> I also support Rod's suggestion to replace references to "classic" ECN
>> with RFC3168 ECN.
> Ditto. Reasons?


This is mostly semantics and possible conotations of the prose-term
"classic". When I followed the discussion around this, it appeared to me
that while this is not objectable to native speakers, non-native english
speakers may have a different set of conotations attached to specific words.

In this context, RFC3168 is as neutral and specific as it can get. Thus
it appears to me, that this would be less contended reference.

Hope this helps.

Richard