From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from p-mail1.rd.orange.com (p-mail1.rd.orange.com [195.101.245.15]) by huchra.bufferbloat.net (Postfix) with ESMTP id 8C0EC21F113 for ; Fri, 9 Aug 2013 06:06:40 -0700 (PDT) Received: from p-mail1.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id C608A410296; Fri, 9 Aug 2013 15:06:39 +0200 (CEST) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.orange.com (Postfix) with ESMTP id CD278410261; Fri, 9 Aug 2013 15:06:38 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Aug 2013 15:06:38 +0200 Received: from [10.193.161.45] ([10.193.161.45]) by ftrdmel10.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Aug 2013 15:06:38 +0200 Message-ID: <5204E95D.30801@orange.com> Date: Fri, 09 Aug 2013 15:06:37 +0200 From: MUSCARIELLO Luca OLNC/OLN User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8 MIME-Version: 1.0 To: Luigi Rizzo 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> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030701040304010108090000" X-OriginalArrivalTime: 09 Aug 2013 13:06:38.0100 (UTC) FILETIME=[484F8540:01CE9501] 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 Reply-To: MUSCARIELLO Luca OLNC/OLN 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 13:06:41 -0000 This is a multi-part message in MIME format. --------------030701040304010108090000 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 08/09/2013 01:30 PM, Luigi Rizzo wrote: > > > On Fri, Aug 9, 2013 at 1:02 PM, MUSCARIELLO Luca OLNC/OLN > > 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 --------------030701040304010108090000 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
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@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



--------------030701040304010108090000--