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

[Jonathan Morton <[e-mail]>]

> On 9 Mar, 2021, at 2:37 pm, Sebastian Moeller <[e-mail]> wrote:
> 
> 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.

This is true IMHO.  FQ still has a significant advantage here, in that latency effects are still isolated between flows; sparse flows, which are typically more latency-sensitive, are not affected by the various saturating flows rushing past them on all sides.  That would not necessarily be true with a single queue.

> 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?

This is similar in effect to what Cake can be configured to do.  Cake does it by weighting the delivery rate of individual flows to produce a constant total weight per host.

Since this seems to be a fairly common use case for ISPs, I'm considering writing a qdisc specialised to do it efficiently.  This could be a drop-in replacement for an fq_codel or HTB+fq_codel deployment, assuming the device needing it is running a new enough kernel.

 - Jonathan Morton