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

[Pete Heist <[e-mail]>]

Hi Sebastian, one comment below...

On Tue, 2021-03-09 at 13:37 +0100, Sebastian Moeller wrote:
> 
> > 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?

Separating capacity fairly between members is exactly what they'd want,
yes. In this coop there aren't any limits.

I should have mentioned before that there _is_ actually a crude host
fairness mechanism in place, using u32 hashing filters on the last
octet of the IP address, and 256 fq_codel instances. It's slow when
enabling and not ideal, so hasn't been used thus far, but it works.

fq_codel does make things better than the status quo, it's just that we
can imagine something that's more suited for ISP usage out of the box,
making it easier and more efficient to split capacity than by many tc
classes and filters. This was discussed in the bufferbloat circles at
some point too.

That's the long way of explaining how they started using fq_codel,
coming back to that original question. :) We do know that other ISPs
are doing the same, in various ways, so it's not a unique usage.

Pete

> Best Regards
>         Sebastian