General list for discussing Bufferbloat
 help / color / mirror / Atom feed
From: Luigi Rizzo <rizzo@iet.unipi.it>
To: "MUSCARIELLO Luca OLNC/OLN" <luca.muscariello@orange.com>
Cc: Paolo Valente <paolo.valente@unimore.it>,
	bloat <bloat@lists.bufferbloat.net>
Subject: Re: [Bloat] Fw: video about QFQ+ and DRR
Date: Fri, 9 Aug 2013 13:30:36 +0200	[thread overview]
Message-ID: <CA+hQ2+iSUoyCoqQY_cSq34rw3dTQ8oTC=SKDrpt4q6a=W02KyA@mail.gmail.com> (raw)
In-Reply-To: <5204CC3E.6070400@orange.com>

[-- Attachment #1: Type: text/plain, Size: 1468 bytes --]

On Fri, Aug 9, 2013 at 1:02 PM, MUSCARIELLO Luca OLNC/OLN <
luca.muscariello@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.

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.

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

cheers
luigi

[-- Attachment #2: Type: text/html, Size: 2211 bytes --]

  reply	other threads:[~2013-08-09 11:30 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-08 15:49 Stephen Hemminger
2013-08-08 16:09 ` Luigi Rizzo
2013-08-09  6:45   ` MUSCARIELLO Luca OLNC/OLN
2013-08-09  7:59     ` Paolo Valente
2013-08-09  8:48       ` MUSCARIELLO Luca OLNC/OLN
2013-08-09  9:35         ` Paolo Valente
2013-08-09 11:02           ` MUSCARIELLO Luca OLNC/OLN
2013-08-09 11:30             ` Luigi Rizzo [this message]
2013-08-09 13:06               ` MUSCARIELLO Luca OLNC/OLN
2013-08-09 13:53                 ` Paolo Valente
2013-08-09 16:08                 ` Dave Taht
2013-08-12  8:28                   ` [Bloat] " Paolo Valente

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/bloat.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CA+hQ2+iSUoyCoqQY_cSq34rw3dTQ8oTC=SKDrpt4q6a=W02KyA@mail.gmail.com' \
    --to=rizzo@iet.unipi.it \
    --cc=bloat@lists.bufferbloat.net \
    --cc=luca.muscariello@orange.com \
    --cc=paolo.valente@unimore.it \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox