From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-iy0-f171.google.com (mail-iy0-f171.google.com [209.85.210.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 E5DC62004FD for ; Wed, 8 Jun 2011 08:00:16 -0700 (PDT) Received: by iyi20 with SMTP id 20so749688iyi.16 for ; Wed, 08 Jun 2011 08:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=86tEAVeoFalql3FUEvldCxu+790VrC5ED3AlW1n8f2E=; b=NqSmY1ZzzKqUoeedOO+yj98VnuDdkD6GNNqf07qgpStu5cXrXeKHZmXG3SmxsoJVg6 onvSB32HsNQLQdEC6Ur4jsnvLWMYGYmh0cgJlrTVEz0FkgMN/Op0NK5bWabEIrTQ0g9L NWKj4jOh+8tD08OTNXWk3zhUB3hY/g86u+N48= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=bMxubCnxDmJIF1YOoxjG/WduXOEQYAl/6KSS9nhLX9e76AxRxx9SkRQhEiJJdiNbWd 5sVtDXzFF+q0oWXcHrA83c1N+9MAk6iHDFI/zXdwT9VvtzAcJk9qe7wotq8vmZ9kmjua DmorzpncAyuXYCKY2wPEw/fYVh6oOnpUIMBUg= MIME-Version: 1.0 Received: by 10.231.68.202 with SMTP id w10mr11977135ibi.63.1307546447166; Wed, 08 Jun 2011 08:20:47 -0700 (PDT) Received: by 10.231.13.76 with HTTP; Wed, 8 Jun 2011 08:20:47 -0700 (PDT) In-Reply-To: <1307545032.3057.45.camel@edumazet-laptop> References: <1307537773.3057.17.camel@edumazet-laptop> <1307545032.3057.45.camel@edumazet-laptop> Date: Wed, 8 Jun 2011 09:20:47 -0600 Message-ID: From: Dave Taht To: Eric Dumazet Content-Type: multipart/alternative; boundary=0015177407d082bc4b04a534e10e 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 15:00:17 -0000 --0015177407d082bc4b04a534e10e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On Wed, Jun 8, 2011 at 8:57 AM, Eric Dumazet wrote= : > Le mercredi 08 juin 2011 =E0 08:04 -0600, Dave Taht a =E9crit : > > 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 agree that the new (1997) solution for SFQ, embedding the ESFQ principle is better. It's NOT embedded in the shaper scripts I've been playing with, it certainly seems saner for flows into the home to be doing it against des= t ips rather than ips and port numbers, in the bittorrent age. I will also attempt to argue persuasively that having ECN packet marking in HTB and elsewhere - when possible - in addition to packet drop would probably result in better behavior overall, but to do that well would require coding it up. The core argument would be: By the time a packet gets to a RED sub-qdisc, it's already been through HTB= , and dropped if it is overlimit. RED has it's own idea as to the 'bandwidth' available, and does not understand what it's getting has already been shape= d by HTB. > > > 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 =3D=3D 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 =3D 3 ms > max_time =3D 30 ms > probability =3D 0.05 > limit_time =3D 100 ms > > This sounds promising also. --=20 Dave T=E4ht SKYPE: davetaht US Tel: 1-239-829-5608 http://the-edge.blogspot.com --0015177407d082bc4b04a534e10e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Wed, Jun 8, 2011 at 8:57 AM, Eric Dum= azet <eric.d= umazet@gmail.com> wrote:
Le mercredi 08 juin 2011 =E0 08:04 -0600, Dave Taht a =E9crit :
> It looks like adding ECN to the other qdiscs would b= e 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 certainl= y
> 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 agree t= hat the new (1997) solution for SFQ, embedding the ESFQ principle is better= . It's NOT embedded in the shaper scripts I've been playing with, i= t certainly seems saner for flows into the home to be doing it against dest= ips rather than ips and port numbers, in the bittorrent age.

I will also attempt to argue persuasively that having ECN packet markin= g in HTB and elsewhere - when possible - in addition to packet drop would p= robably result in better behavior overall, but to do that well would requir= e coding it up.

The core argument would be:

By the time a packet gets to a RED s= ub-qdisc, it's already been through HTB, and dropped if it is overlimit= . RED has it's own idea as to the 'bandwidth' available, and do= es not understand what it's getting has already been shaped by HTB.

=A0


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 =3D=3D 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 :
=A0 =A0 =A0 =A0min_time =3D 3 ms
=A0 =A0 =A0 =A0max_time =3D 30 ms
=A0 =A0 =A0 =A0probability =3D 0.05
=A0 =A0 =A0 =A0limit_time =3D 100 ms


This sounds promising also.
=A0



--
Dave T=E4ht
SKYPE: davetaht
US Tel= : 1-239-829-5608
http://the-edge.blogspot.com
--0015177407d082bc4b04a534e10e--