Re: [tsvwg] New Version Notification for draft-heist-tsvwg-ecn-deployment-observations-02.txt

[Sebastian Moeller <[e-mail]>]

> On 08/03/2021 22:19, Pete Heist wrote:
[...]
>> IMO, fq_codel isn't ideal in this situation. When there actually is
>> congestion to manage, flow-fairness means that one user can dominate
>> the queue with many flows, which is exactly one of the problems we'd
>> like to avoid. Host fairness could improve on this, or better yet,
>> member fairness using the member database, as members can have more
>> than one IP/MAC. But, fq_codel is what's available now, and generally
>> usable enough in this case to get started with AQM.

[...]



> On Mar 9, 2021, at 01:25, Bob Briscoe <[e-mail]> wrote:
[...]
> PS. I agree it's v strange for an ISP to share capacity between its members by how many flows they are using.
[...]



I just want to note two things here:

a) even without a flow queueing AQM on the bottleneck, sharding works to get a higher part of the capacity since TCP tends to be more or less fair to itself

b) most ISP put a lid on games like that by simply also enforcing (policing or shaping) each users aggregate capacity to numbers mentioned in the contract...

So fq_codel, while by no means ideal here, does not really make thinks worst that the status quo, it is just that sharding can make pure flow fairness regress to less equitable sharing between classes other than flows.

For a cooperative use case, something like a per-member QFQ instance that equitably shares capacity between members with an fq_codel inside each of the QFQ classes seems like a better fit, no?

Best Regards
	Sebastian