From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) (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 6CD3821F16A for ; Tue, 20 May 2014 15:11:53 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id a108so1856462qge.39 for ; Tue, 20 May 2014 15:11:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-type:thread-index:content-language; bh=HuhobkHzYna3k9Lyi8Cv2jw63RVyCufEUM1Va1TSwfQ=; b=jNziWeB1bl9cjRc54feLmW92arR0KrKNSjuYD9yzdwG5V8XbuXV2XWFn/C6Y7r7+Lz /ph7XuQA3IZr6GQMOQ864J4E+TsPn33lt+FtAJsPff42ZGmAIFdKBxFKg5ft+u3K9Vqk 0NEPc5bVLsYMSxwl5EbZSHTwGB8g6S0wQ9U2OEJoIf9WvrayhpVC2wN5KvoC1OcO9a0z WbRtFKValVmuCpUnZ35TYtum/vYW7KAqBpOhCkNerHdFxrZ96H30ng7Qk3f5dZsxBIil 2d6WbsPtSrJMbLZVwVAxnjT1CVnFMe+8sQzu7USrlc1s0X5urwOOzEnDgHo6/CIUR3Uz y0PQ== X-Gm-Message-State: ALoCoQlETLmw3tptLlB7YSIwLXTJqIWWZUOvQ8aTky5kyNeXTWiticlopb9JRNrbCn4mGsGIZ4S0 X-Received: by 10.224.87.132 with SMTP id w4mr49413287qal.89.1400623912069; Tue, 20 May 2014 15:11:52 -0700 (PDT) Received: from RiepPCAcer (static-98-118-126-86.bstnma.fios.verizon.net. [98.118.126.86]) by mx.google.com with ESMTPSA id u7sm1665161qat.2.2014.05.20.15.11.50 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 20 May 2014 15:11:51 -0700 (PDT) From: "Frits Riep" To: Date: Tue, 20 May 2014 18:11:50 -0400 Message-ID: <006001cf7478$804951e0$80dbf5a0$@riepnet.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01CF7456.F93B3450" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac90deBooCZoJeWRSXKDjWk/3DlgLQ== Content-Language: en-us Subject: [Cerowrt-devel] Ideas on how to simplify and popularize bufferbloat control for consideration. 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: Tue, 20 May 2014 22:11:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0061_01CF7456.F93B3450 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit The concept of eliminating bufferbloat on many more routers is quite appealing. Reading some of the recent posts makes it clear there is a desire to get to a stable code, and also to find a new platform beyond the current Netgear. However, as good as some of the proposed platforms maybe for developing and for doing all of the new capabilities of CeroWRT, I also would like to propose that there also be some focus on reaching a wider and less sophisticated audience to help broaden the awareness and make control of bufferbloat more available and easier to attain for more users. . It appears there is a desire to merge the code into an upcoming OpenWRT barrier breaker release, which is excellent as it will make it easier to fight buffer bloat on a wide range of platforms and provide users with a much easier to install firmware release. I'd like to be able to download luci-qos-scripts and sqm-scripts and have basic bufferbloat control on a much greater variety of devices and to many more users. From an awareness perspective this would be a huge win. Is the above scenario what is being planned, is it likely to happen in the reasonable future? . From my perspective, it would be ideal to have this available to many users in a more affordable platform, something like an 8mb flash router like the TP-Link WDR-4300, which is otherwise a very capable router with dual channels and good performance. . (I've managed to set up such a WDR-4300, with OpenWRT trunk, figured how to telnet and install Luci, then luci-app-qos, and qos-scripts and I thought the bufferbloat control was remarkable.) How much better would it be if I were able to use luci-qos-scripts and sqm-scripts instead? . For these target users, they need simplicity, good performance, ease of setup and affordability. They are not able to deal with the routing between subnets on wireless, IPv6 setup, and any complexities introduced by DNSSEC. Marketing the advantages of bufferbloat alone requires lots of education and publicity (and as we have seen there are many misleading posts by seemingly persuasive nay-sayers that it is all smoke and mirrors. . Would it be possible to have a simplified release of CeroWRT (in terms of setup, and features), make It available for a reliable and affordable platform, and publicize it and have it reach hopefully a much wider audience? This could potentially be through the OpenWRT channels. . Part of the reason why Tomato had been so popular is that the firmware upgrade, install, configuration, and management was well within the capabilities of the average weekend hacker, and there were compelling features and reliability vs the factory firmwares at the time. . Even installing OpenWRT, especially Trunk, and finding, downloading and enabling packages, while very powerful, and flexible, is still quite complex to someone who does not spend a lot of time reading wiki's and release notes. I'd be interested in feedback on these thoughts. Frits Riep ------=_NextPart_000_0061_01CF7456.F93B3450 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

The = concept of eliminating bufferbloat on many more routers is quite = appealing.  Reading some of the recent posts makes it clear there = is a desire to  get to a stable code, and also to find a new = platform beyond the current Netgear.  However, as good as some of = the proposed platforms maybe for developing and for doing all of the new = capabilities of CeroWRT, I also would like to propose that there also be = some focus on reaching a wider and less sophisticated audience to help = broaden the awareness and make control of bufferbloat more available and = easier to attain for more users.

 

·         = It appears there is a desire to merge the = code into an upcoming OpenWRT barrier breaker release, which is = excellent as it will make it easier to fight buffer bloat on a wide = range of platforms and provide users with a much easier to install = firmware release.  I’d like to be able to download = luci-qos-scripts and sqm-scripts and have basic bufferbloat control on a = much greater variety of devices and to many more users.  From an = awareness perspective this would be a huge win.  Is the above = scenario what is being planned, is it likely to happen in the reasonable = future?

·         = From my perspective, it would be ideal to = have this available to many users in a more affordable platform, = something like an 8mb flash router like the TP-Link WDR-4300, which is = otherwise a very capable router with dual channels and good = performance.

·         = (I’ve managed to set up such a = WDR-4300, with OpenWRT trunk, figured how to telnet and install Luci, = then luci-app-qos, and qos-scripts and I thought the bufferbloat control = was remarkable.)  How much better would it be if I were able to use = luci-qos-scripts and sqm-scripts instead?

·         = For these target users, they need = simplicity, good performance, ease of setup and affordability.  = They are not able to deal with the routing between subnets on wireless, = IPv6 setup, and any complexities introduced by DNSSEC.  Marketing =  the advantages of bufferbloat alone requires lots of education and = publicity (and as we have seen there are many misleading posts by = seemingly persuasive nay-sayers that it is all smoke and = mirrors.

·         = Would it be possible to have a simplified = release of CeroWRT (in terms of setup, and features), make It available = for a reliable and affordable platform, and publicize it and have it = reach hopefully a much wider audience?  This could potentially be = through the OpenWRT channels.

·         = Part of the reason why Tomato had been so = popular is that the firmware upgrade,  install, configuration, and = management was well within the capabilities of the average weekend = hacker, and there were compelling features and reliability vs the = factory firmwares at the time.

·         = Even installing OpenWRT, especially = Trunk, and finding, downloading and enabling packages, while very = powerful, and flexible, is still quite complex to someone who does not = spend a lot of time reading wiki’s and release = notes.

 

I’d be interested in feedback on these = thoughts.

 

Frits = Riep

 

------=_NextPart_000_0061_01CF7456.F93B3450--