From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by huchra.bufferbloat.net (Postfix) with ESMTPS id 84F6F21F0BD for ; Fri, 20 Dec 2013 09:34:16 -0800 (PST) Received: by mail-we0-f181.google.com with SMTP id x55so2813766wes.12 for ; Fri, 20 Dec 2013 09:34:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=x7qdSMuXHf2s0YsyZ1Rx9RZLH5ABI0n9dwhP+5jd0WY=; b=NWieDrDlHPP7lhdqXb+4bTrBJYgtKhnqnWLLaJrIINt6yLbgp8hXFDHgYKPfwUxLD/ e0JGiPbtq7X4yi5Sq1Zqw0wgUmwsPbAMh30U4A84M/efLEYcORRb1fq22Q7b0uNu7Vfp dpnr+lDN7ykdKm0UQb7OizLgaVN2vHqC2C95CJnqpkwHInUyK/aJv1FlH8yeMXI4FHxL L3a4XwVEp9vBk73X3qE8TLzLy1o+9H1xIT0tV/J//s3tUikieTGF5GhWDjLzkbn3x8T2 /yc4NocTsYWSCj0+e5YDSUq80vDKDzN/64uw6NK4SaOEz9bOsPP22DhFaoqpYy9fzMdD PfFw== MIME-Version: 1.0 X-Received: by 10.180.37.69 with SMTP id w5mr8791972wij.53.1387560854098; Fri, 20 Dec 2013 09:34:14 -0800 (PST) Received: by 10.217.123.69 with HTTP; Fri, 20 Dec 2013 09:34:13 -0800 (PST) In-Reply-To: References: <34E77F64-739C-49E4-B8A4-6ABBEAE4174B@gmail.com> <8DB84101-C942-49C4-99F0-6C9319961297@gmail.com> <22176178-A50F-48F2-A3A1-D3853764AD0E@gmail.com> <0E267F91-3CC8-48F4-92C0-AD8BACA98FCC@gmail.com> <1FA2FD44-D715-4B50-BB5A-BAF61070970B@gmx.de> <31B5B61B-4E58-4C5E-8F33-710CCE0918F4@gmail.com> Date: Fri, 20 Dec 2013 09:34:13 -0800 Message-ID: From: Dave Taht To: Rich Brown Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [Cerowrt-devel] CeroWrt 3.10 AQM page X-BeenThere: cerowrt-devel@lists.bufferbloat.net X-Mailman-Version: 2.1.13 Precedence: list List-Id: Development issues regarding the cerowrt test router project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 17:34:17 -0000 What's in a name? AQM has been pretty thoroughly defined to equal active queue *length* management and not packet scheduling. Overloading "AQM" what cerowrt does is apt to cause even more confusion in the field than it already does. We discussed using LBO as a word but that appears hopelessly overloaded with leveraged buy out. I go back to one I liked a while back: Smart Queue Management. (SQM) This got dissed on the aqm list too, but so far a viable alternative TLA has not appeared. It's sufficiently different to hang a different definition off of ("Smart queue management is an intelligent combination of better packet scheduling (flow queuing) techniques along with with active queue length management (aqm)") On Thu, Dec 19, 2013 at 5:42 AM, Rich Brown wrote= : > Hi Sebastian and Fred, > > [I=92m changing the subject line of this thread=85] > > Great comments. I knew my glib assertions and fuzzy explanations would br= ing out cogent thoughts. I=92ll give the rest of the list a chance to perus= e the draft page and then work on it tonight. > > http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_CeroW= rt_310 > > Rich > > > On Dec 19, 2013, at 5:49 AM, Sebastian Moeller wrote: > >> Hi Rich, >> >> >> On Dec 19, 2013, at 05:12 , Rich Brown wrote: >> >>> Hi Sebastian, >>> >>>>> Perhaps we could extend the Interface configuration page to add a =93= Link uses DSL/ADSL:=94 checkbox right below the Protocol dropdown. Default = would be off, but when customers go to the GE00 interface to enter their PP= PoE/PPPoATM/ISP credentials, they=92d see this additional checkbox. Checkin= g it would feed that info to the AQM tab. (And perhaps there could be a lin= k there either to the AQM tab, or to the wiki for more information.) >>>> >>>> I am happy to include a link to a wiki, but I guess we first need = a wiki page :) >>> >>> Is this a challenge? Well, I accept! :-) >>> >>> http://www.bufferbloat.net/projects/cerowrt/wiki/Setting_up_AQM_for_Cer= oWrt_310 is a draft. I recycled the images from a previous message and wrot= e the least amount that I could that is likely to be true. >> >> This is great, thanks a lot. I have made a few changes to the GUI = yesterday, which hopefully improve the usability, so if the new GUI passes = muster with the cerowrt crowd, the screenshots will need to change as you n= ote on top. >> >>> >>> Please send me comments (or edit the page directly, if you have permiss= ions.) >> >> I do not have edit permissions, so I just comments here. >> >> Basic settings: >> Why 85% as starting point? And can we give instructions how to mea= sure "degradation in performance", so that non-technical users have a chanc= e to actually optimize their own system? >> >> Queueing Discipline: >> Maybe we can add a link to the mail list page (https://lists.buffe= rbloat.net/listinfo/cerowrt-devel)? >> Also can we note that it is recommended to turn ECN off for the eg= ress, as we handle packets before the bottleneck and dropping packets actua= lly allows us to send other more urgent packets , while on ingress it is re= commended to turn ECN on, as the packets have cleared the bottleneck alread= y, and hence dropping has no bandwidth advantage anymore. Both dropping and= ECN should have the same effect on TCP adaptation to the path capacity. >> >> Link Layer Adaptation: >> I think the first question is: Do I have an ATM carrier between yo= ur modem and your ISP's DSLAM? This typically is true for all ADSL variants= . >> The second question is: Do I have overhead on the link outside of = Ethernet framing? This typically is true for users of PPPoE and PPPoATM and= even Bridging I think. >> >> If the answer to any of these questions is yes, one needs to activ= ate the link layer adaptations. >> In case of pure overhead select ethernet, in case of ADSL select A= TM. >> Fill in the per packet overhead in byte (see: http://ace-host.stua= rt.id.au/russell/files/tc/tc-atm/, http://web.archive.org/web/2010052702452= 0/http://www.adsl-optimizer.dk/ and http://www.faqs.org/rfcs/rfc2684.html).= If the overhead truly is zero and no ATM carrier is used, then select "non= e" for link layer adaptation. (I changed this page, so the tc_stab htb_priv= ate selection is under advanced options, and there is a selection of "none"= , "ethernet", and "none" in the first drop down box, "none" disables the li= nk layer adaptation. Also the drop down box contains some information which= selection is relevant for which cases). >> >> What=92s going on here? Why do I need this?: >> I think we should mention that only with the proper link layer sel= ected and the overhead specified cerowrt is able to assess how large each p= acket is on the link to the ISP, and only then the shaping is deterministic= . (For ATM users without the adaptations the shaper is stochastically too o= ptimistic about the link capacity (which is too say the shaper is too optim= istic about the effective packet sizes)). >> >> Best Regards >> Sebastian >> >> >> >>> Thanks. >>> >>> Rich >> > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel --=20 Dave T=E4ht Fixing bufferbloat with cerowrt: http://www.teklibre.com/cerowrt/subscribe.= html