From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-la0-x235.google.com (mail-la0-x235.google.com [IPv6:2a00:1450:4010:c03::235]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 6C70021F14D for ; Fri, 9 Aug 2013 04:30:39 -0700 (PDT) Received: by mail-la0-f53.google.com with SMTP id el20so314939lab.12 for ; Fri, 09 Aug 2013 04:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=adoseUWwFuJI6k0YnJ+1j7+Aro7ub+aVckfFbnS59TA=; b=V4VmDxdTZOJRlhkxNcx7LN01KuOeQpwmvSr/BbI6+k9toyMweMYDMIzEWRMCC6bcjl KEh8xl8g4Bljw3BJmP2ImxX0iM2AwyV3ugiKnYOcwATfu8LaFmhXx2iRYZcw7Wf8d2eU exlezXFL59kKDL7elbs3j1y5T7vTbvpjwmU4HlXSX750hApVjTDyYD8a74qFlNgpgbIU yrPVQw7+5JbYibkf1b+l2JUb4fOtCIJ6DuG13+zJ37NbFGOugEPd1z08CRQgSb6t3VRZ Fou+lUdpwKh0+JjNOaiQCo9y1ryAA3VFV11Mp7p6DKmV8RIynEhaoiKI4pq0FYSIyzIk 99aw== MIME-Version: 1.0 X-Received: by 10.112.11.20 with SMTP id m20mr4301444lbb.56.1376047836654; Fri, 09 Aug 2013 04:30:36 -0700 (PDT) Sender: rizzo.unipi@gmail.com Received: by 10.114.200.165 with HTTP; Fri, 9 Aug 2013 04:30:36 -0700 (PDT) In-Reply-To: <5204CC3E.6070400@orange.com> References: <20130808084920.7ebc306d@nehalam.linuxnetplumber.net> <52048FF7.8040200@orange.com> <95C41B2E-6946-44DF-B2F2-ED711609CF67@unimore.it> <5204ACCE.50006@orange.com> <5204CC3E.6070400@orange.com> Date: Fri, 9 Aug 2013 13:30:36 +0200 X-Google-Sender-Auth: fsGY2Bkb6GFVPkbn904Ra4qiNkY Message-ID: From: Luigi Rizzo To: "MUSCARIELLO Luca OLNC/OLN" Content-Type: multipart/alternative; boundary=001a1133eb747f72f804e3821af2 Cc: Paolo Valente , bloat Subject: Re: [Bloat] Fw: video about QFQ+ and DRR X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Aug 2013 11:30:40 -0000 --001a1133eb747f72f804e3821af2 Content-Type: text/plain; charset=ISO-8859-1 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 --001a1133eb747f72f804e3821af2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Fri, Aug 9, 2013 at 1:02 PM, MUSCARIELLO Luca OLNC/OLN <l= uca.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 (co= rrect 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 p= ackets 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,<= br> 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 ha= ppen
to have 500 flows (active and in progress ) on a link.


think of an ISP that sells bandwidth t= o multiple customers.
Then you really want to have one class per = customer, instead
of imposing hard limits on each of them (leadin= g to poor use
of spare resources), or putting all of them in the same bucket.
<= div>
As a matter of fact, for almost a decade ISPs in various= places
have been using ipfw+dummynet (which includes qfq and oth= er schedulers)
to sell bandwidth to customers.

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

cheers
luigi
--001a1133eb747f72f804e3821af2--