Re: [tsvwg] FW: path forward on L4S issue #16

[Steven Blake <[e-mail]>]

On Mon, 2020-06-08 at 13:32 +0000, Black, David wrote:

> As an alternative, I suggest starting from Neil Cardwell's network
> and operator perspective (from 
> https://mailarchive.ietf.org/arch/msg/tsvwg/kyDZ7vYLeOk1V15nZfNXGmaUNxk/):
> 
> 	- L4S flows potentially causing unfairness in RFC3168 ECN bottlenecks has
> 	been mentioned as a potential concern. However, a robust RFC3168 ECN
> 	bottleneck should already have a mechanism to avoid unfairness caused by
> 	flows that are marked as ECT(0|1) and yet not performing RFC3168 responses.
> 	In particular, many of the large sources of known deployments of  RFC3168
> 	--  Linux fq_codel and cake -- are already deployed with fair queueing. In
> 	such bottlenecks L4S traffic should not cause harm to other non-L4S flows.
> 	Furthermore, if there really are ISPs with deployments of RFC3168
> 	bottlenecks that have neither FQ nor any other protection from
> 	non-RFC3168-ECT(1) flows, then they can bleach incoming ECT(1) code points
> 	to Not-ECT and treat L4S as Not-ECT (ISPs typically already transform the
> 	DSCP byte at their ingress anyway). So I do not see harm to RFC3168 ECN
> 	bottlenecks as a prohibitive concern.

My cursory examination turned up zero evidence that any major vendor
has implemented any sort of AQM/ECN "penalty box" fairness enforcement
mechanisms in carrier gear, at least above the access edge. If anyone
has some evidence, please speak up.

> 	- More generally, if there is any problem discovered with the L4S
> 	experiment, either the algorithm or particular implementations, bottlenecks
> 	can easily identify L4S traffic and bleach it into Not-ECT, and treat it
> 	like Reno/CUBIC traffic.

If there is even a non-trivial probability that this could be the
outcome, how can anyone argue in good faith that L4S traffic should not
be classified by DSCP?


Regards,

// Steve