From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from r-mail2.rd.orange.com (r-mail2.rd.orange.com [217.108.152.42]) by huchra.bufferbloat.net (Postfix) with ESMTP id 3952E21F113 for ; Fri, 9 Aug 2013 04:02:25 -0700 (PDT) Received: from r-mail2.rd.orange.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 227585D8ADB; Fri, 9 Aug 2013 13:02:23 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail2.rd.orange.com (Postfix) with ESMTP id 158735D892A; Fri, 9 Aug 2013 13:02:23 +0200 (CEST) Received: from ftrdmel10.rd.francetelecom.fr ([10.192.128.44]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 9 Aug 2013 13:02:23 +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 13:02:22 +0200 Message-ID: <5204CC3E.6070400@orange.com> Date: Fri, 09 Aug 2013 13:02:22 +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: Paolo Valente References: <20130808084920.7ebc306d@nehalam.linuxnetplumber.net> <52048FF7.8040200@orange.com> <95C41B2E-6946-44DF-B2F2-ED711609CF67@unimore.it> <5204ACCE.50006@orange.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Aug 2013 11:02:22.0700 (UTC) FILETIME=[EC8BC2C0:01CE94EF] Cc: 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 11:02:25 -0000 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. I think both are needed but while class-based queuing is well accepted flow-based is not. Luca