From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wy0-f171.google.com (mail-wy0-f171.google.com [74.125.82.171]) (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 660212004FD for ; Wed, 8 Jun 2011 07:36:47 -0700 (PDT) Received: by wyb32 with SMTP id 32so598973wyb.16 for ; Wed, 08 Jun 2011 07:57:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:subject:from:to:cc:in-reply-to:references :content-type:date:message-id:mime-version:x-mailer :content-transfer-encoding; bh=FpSSO2qVqPjxRB1ww7NWx/zF9utWsjCQlCIXbjScb3U=; b=uWOMBT0Y0k71prgQWyzykcg7RhlRtypSAeR45lPAnmq71fl6FlqidlUdStHwuHeJ8l Y+Ay9u9mlOohdFowXYDGKLareUJRBhCcvzCNT7oXIjcNeAomincEnGaIOryVQHw9uCKy jRZWN1dHNJq2/m6lE6fv11jRWpa8y6TOBIzvk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:x-mailer:content-transfer-encoding; b=I0QC961YBeNtvnkIZmrM7NW7c1Bo60y5nWSfh5Kc+4tJDmlKYKGVzYFbZ+dGX/Tdqu rWuyL9sQCr6OzhpxVSNbfYZlgOUfSlygWm9xHEqbH70fgX7HYOXxvfWrvkoT7MqEyaYS HtZMuF3d7ycG2IQGqLyEj0gRx1T7eK3zf1dhw= Received: by 10.216.159.75 with SMTP id r53mr7308033wek.98.1307545035689; Wed, 08 Jun 2011 07:57:15 -0700 (PDT) Received: from [10.150.51.210] (gw0.net.jmsp.net [212.23.165.14]) by mx.google.com with ESMTPS id 74sm327808wem.41.2011.06.08.07.57.14 (version=SSLv3 cipher=OTHER); Wed, 08 Jun 2011 07:57:14 -0700 (PDT) From: Eric Dumazet To: Dave Taht In-Reply-To: References: <1307537773.3057.17.camel@edumazet-laptop> Content-Type: text/plain; charset="UTF-8" Date: Wed, 08 Jun 2011 16:57:12 +0200 Message-ID: <1307545032.3057.45.camel@edumazet-laptop> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 8bit Cc: bloat Subject: Re: [Bloat] Notes about hacking on AQMs 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: Wed, 08 Jun 2011 14:36:48 -0000 Le mercredi 08 juin 2011 à 08:04 -0600, Dave Taht a écrit : > It looks like adding ECN to the other qdiscs would be good, and > transparent to the upper layers, but a 10 minute glance at HTB seems > to make it a non-trivial exercise. But that's me. I would certainly > like to see ECN asserted more often than it is. Thoughts? Just add to your HTB some RED qdisc ? You have a framework to build whatever is needed. Dont try to use a "single magic thing that will solve all my problems". This reminds me the ESFQ attempt : Patrick prefered to plug an external classifier in SFQ, instead of adding specialized code in each possible Qdisc. I had the idea to add ECN to SFQ (my favorite qdisc for proxies dealing only with tcp flows) in the past, with a global config (shared for all flows : remember SFQ means Fair Queuing ;) ) At queueing time : - we compute the flow (internal default SFQ classifier, or external user provided one) - We queue the packet into its slot X (kind of pfifo) - If queue limit is reached, take a packet from the biggest slot Y, do a head drop. Return Congestion Notification to caller if the chosen slot is the slot X (X == Y) Adding ECN/RED here could be done with very litle added cost : Adding kind of RED on each slot, instead of a regular pfifo, and probabilist mark/drop packet at enqueue time if : - Current slot length is above the RED lower threshold - Or average residency time in slot above a threshold And doing full drop if : - Current slot length is above RED upper limit - Current elapsed time of head packet above upper time limit. I like the time being the feedback instead of queue length (hard to tune, especially if bandwidth is unknown) You would say for example : min_time = 3 ms max_time = 30 ms probability = 0.05 limit_time = 100 ms