[Bloat] Fw: video about QFQ+ and DRR

MUSCARIELLO Luca OLNC/OLN luca.muscariello at orange.com
Fri Aug 9 09:06:37 EDT 2013


On 08/09/2013 01:30 PM, Luigi Rizzo wrote:
>
>
> On Fri, Aug 9, 2013 at 1:02 PM, MUSCARIELLO Luca OLNC/OLN 
> <luca.muscariello at orange.com <mailto:luca.muscariello at orange.com>> wrote:
>
>
>     On 08/09/2013 11:35 AM, Paolo Valente wrote:
>
>             >1) AFAIK, sch_drr.c is class-based queuing and not
>             per-flow queuing (correct me if I am wrong).
>
>         Certainly it is a classful queueing discipline. Just to sync
>         with you, what do you mean with per-flow as opposed to
>         class-based?
>         Do you mean that the scheduler internally and autonomously
>         differentiates packets into distinct flows according to some
>         internal classification rule (as it is the case for SFQ)?
>         If so, then you are right.
>
>
>     Class-based queuing and flow-based queuing of course are different
>     things,
>     but from your demo I got the impressions that you were using class
>     and flow
>     interchangeably.
>
>     In practice, I do not see when you would need 500 classes while it
>     might happen
>     to have 500 flows (active and in progress ) on a link.
>
>
> think of an ISP that sells bandwidth to multiple customers.
> Then you really want to have one class per customer, instead
> of imposing hard limits on each of them (leading to poor use
> of spare resources), or putting all of them in the same bucket.

This indeed might happen in the BAS for ADSL users.

>
> As a matter of fact, for almost a decade ISPs in various places
> have been using ipfw+dummynet (which includes qfq and other schedulers)
> to sell bandwidth to customers.

I only see the VPN market where this might happen (QoS in various places),
however queuing is not (hopefully) much deep in the network, and ISPs 
(usually)
rely on link over provisioning; so that classes never compete for bandwidth
(not in the back-haul nor in the transit).

>
> ipfw has some very cheap instructions to flexibly group flows into 
> classes,
> even large numbers of them.

I know, and that's great.
Maybe class is not anymore the right term in this case. It's an 
aggregate of flows,
do not know how to call it but not really a class.

Cheers
Luca



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20130809/6a0d7830/attachment-0003.html>


More information about the Bloat mailing list