Subject: [tsvwg] my backlogged thoughts on the ECT(1) codepoint interim call

From: Pete Heist <[email-masked]>
Date: Wed, 29 Apr 2020 12:07:15 +0200

Speaking now as an individual and engineer:

This decision has been presented using the phrase "ECT(1) as input vs output",
but I think it's more accurately summarized as:

A) Output: ECT(1) as an additional signal of lesser congestion
B) Input: ECT(1) to bifurcate explicit congestion control and select alternate
   bottleneck treatment

I am not sure that all of those who were present on the call understand the
implication of the decision we're making. While option A is guaranteed not to
lead to safety or network bias concerns, option B leaves that up to the 
implementation.

I do not believe that we should introduce any semantics that potentially lead
to preferential treatment at Internet bottlenecks, and question some of the
present thinking that throughput fairness is of little concern. We should
carefully consider the implications of this design decision, including how it
might affect those who do not have access to the latest devices or upgrades.

Those of us actively engaged in signaling option A will continue to move it
forward, but the work that is needed to analyze and report on the implications
of signaling option B is not without cost. That makes this codepoint decision
a good opportunity to make progress and raise the level of awareness.

RFC 7282 lays out how the IETF should not be run by "majority rule", so let's
resist the urge to assemble a crowd and run for the exit, especially when there
may not be universal awareness among those humming of what "ECT(1) as input vs
output" really means. Let's make sure that everyone involved is well informed
of the consequences before any kind of hum or voting process is undertaken,
especially during the present global conditions, when physical meetings are not
possible and the mechanics of how to properly do a "hum" remotely are still not
clear.

While option A may still need more work, option B is not appropriate at
Internet scope. It should be done with a DSCP codepoint, which will restict
usage to domains where it's both useful and safe to implement.

Regards,
Pete Heist