From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) (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 CF59121F3DE for ; Tue, 20 May 2014 16:14:05 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id u56so1224543wes.37 for ; Tue, 20 May 2014 16:14:03 -0700 (PDT) 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=034kLooLIPNLRFKK3E9LYZf88Y0HSgIyQ5Kc6NATLyI=; b=Y4rrJ+0sdvtGu350wvwPBF1HEazWdqVK941JRJw4NcHhX2765LNNVXtPisA2jCrJpF YGYwF0P5C8twggu19grfjyWdBh/ak6k7zREYrVC2sEUFMJ2E3tZcOgWjem7jtHbLh+dA ntQ0RIKs7F0BBFzEy1uBdDAaPtSl6CgM7oFtX56OkGptAMR84PjTa9+v6Ex1wlFeaPEJ mSYnLTR5i6oZCWyin95vusMkiHqezRF/MFh6P0K3KnCtt0edNLG7MQmuIkdXc9YeknUa 2G0hinu2kreT7WRKc0Cz5VSsWliXirKkmaBRb5Eoyg4sHOKxQW9jlX10jqKqLRL8Nuzc 4RNg== MIME-Version: 1.0 X-Received: by 10.180.198.43 with SMTP id iz11mr6950859wic.46.1400627643667; Tue, 20 May 2014 16:14:03 -0700 (PDT) Received: by 10.216.207.82 with HTTP; Tue, 20 May 2014 16:14:03 -0700 (PDT) In-Reply-To: <006001cf7478$804951e0$80dbf5a0$@riepnet.com> References: <006001cf7478$804951e0$80dbf5a0$@riepnet.com> Date: Tue, 20 May 2014 16:14:03 -0700 Message-ID: From: Dave Taht To: Frits Riep Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "cerowrt-devel@lists.bufferbloat.net" Subject: Re: [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 23:14:06 -0000 On Tue, May 20, 2014 at 3:11 PM, Frits Riep wrote: > 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 t= he > current Netgear. However, as good as some of the proposed platforms mayb= e > for developing and for doing all of the new capabilities of CeroWRT, I al= so > would like to propose that there also be some focus on reaching a wider a= nd > less sophisticated audience to help broaden the awareness and make contro= l > of bufferbloat more available and easier to attain for more users. I agree that reaching more users is important. I disagree we need to reach them with cerowrt. More below: > > > =C2=B7 It appears there is a desire to merge the code into an upc= oming > 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 use= rs > with a much easier to install firmware release. I=E2=80=99d like to be a= ble to > download luci-qos-scripts and sqm-scripts and have basic bufferbloat cont= rol > 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 wh= at > is being planned, is it likely to happen in the reasonable future? Yes, I'd submitted sqm for review upstream, got back a few comments. Intend to resubmit again when I get a chance. > > =C2=B7 From my perspective, it would be ideal to have this availa= ble to > many users in a more affordable platform, something like an 8mb flash rou= ter > like the TP-Link WDR-4300, which is otherwise a very capable router with > dual channels and good performance. > > =C2=B7 (I=E2=80=99ve managed to set up such a WDR-4300, with Open= WRT trunk, > figured how to telnet and install Luci, then luci-app-qos, and qos-script= s > 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 instea= d? You can easily add the .ipk files for sqm-scripts and luci-app-sqm to any release of openwrt. They are just scripts. They need some optional kern= el modules and tools. I regard the qos-scripts as pretty good - the core differences from sqm are qos vs sqm --------------- both use fq_codel. :) hfsc vs htb # A wash, hfsc mostly behaves like htb ping optimized vs de-optimized # optimizing for ping looks good in benchmarks but it's silly in the real world (l7) classification vs dscp # clear win to qos here, nearly nothing uses ds= cp no framing compensation vs comprehensive framing compensation # win here fo= r sqm no alternate queue models vs many alternate queue models # with fq_codel the winner, who cares? fits in 4mb flash vs barely fits in 4mb flash The real killer problem for qos-scripts, for me, was that they didn't do ipv6. I'd like to see that fixed, at the very least. > > =C2=B7 For these target users, they need simplicity, good perform= ance, > ease of setup and affordability. They are not able to deal with the rout= ing > 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 po= sts > by seemingly persuasive nay-sayers that it is all smoke and mirrors. Well, my intent is to make the successful bits of technology widely availab= le. They are widely available. And being adopted everywhere. Win. As for the additional complexities, well, they will get less complex over t= ime. In one respect, they are a stake in the ground. I have high hopes for the eventual success of hnetd and mdns proxy services, although they are alpha and nearly unusable right now, some are making substantial investments into them. In another the additional complexities of cero - like routing vs bridging - are there to further the research into fixing wifi technologies - which we haven't really even started yet. I'm increasingly convinced we need to do make-wifi-fast as a separate, focused project, building on a stable base. > =C2=B7 Would it be possible to have a simplified release of CeroW= RT (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. Possible yes. Affordable, no. Given that this has been a nearly full time project for me, for the last 38 months, with nearly zero revenue, I have no intent or interest in gaining anything other than knowledgable, clued users that want to advance the stat= e of the art. My mom doesn't run cerowrt, nor do I want her to. If someone dropped ~1m/year on the project, that could change, but at prese= nt levels of funding I'd be better off working at mcdonalds. Even if funding appeared from the sky I'd rather spend it on R&D than GUI... Certainly IF there was some cost model that made sense, awesome! let's go for world domination! I continue to pursue the grant route, but the only thing that resonates even slightly with potential funde= rs is not speed but security issues, which give me nightmares. Another model that works is actually making and selling a router, but that requires up front capital and entry into a very tight, profit-limited market. Biggest problem we have is supporting ONLY one router, even-semi-well, is a PITA. Adding a new one costs more. I'm now on my 4th day of trying to make the archer work. That's 6k of my life I'll never have back. And the ath10k in i= t sucks, and working to make that work well is not something I want to be doi= ng due to the binary blob wifi firmware. I'm all in favor of handing off future cerowrt development to a nonprofit of interested users, and sitting back and focusing on fixing just the bits I care about, if anyone is interested in forming one... > =C2=B7 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. Yep. dd-wrt is the same. And various downstream users like buffalo, meraki etc. I'm totally happy that they exist and have a working market. > =C2=B7 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=E2=80=99s and release notes. Yes, CeroWrt is an improvement on OpenWrt in that regard. But it isn't enough. Doing serious UI improvements and simplification IS necessary, and that's not my bag. The EFF is making noises about doing something with the front end of openwrt and/or cero in the next year or so (see their owtech list for more details), that also goes after the security issue. > I=E2=80=99d be interested in feedback on these thoughts. There you go. I LOVE that we have a happy userbase, and love what we've accomplished, and have loved being here to help make it happen, and love that lots of people want to get it more out there to more people, it's gratifying as hell, and there are a lot of negatives too, like chasing bugs for months on end... ... but after we freeze, I need a vacation and to do something else for a w= hile. I'm presently planning on spending the summer working on something that pay= s, and on improving ns3 with the GSOC, and testing a deployment of cerowrts on a modest scale, and working on a new/improved rate limiter integrated with fq_codel. And only updating cero for CVEs or major new features. That's a full plate. If someone else wants to step up to maintain or continue to push cerowrt forward in some direction or another, I'm all for it. It's kind of my hope a clear winner on the chipset front will emerge and we can move to that, but even if that happens it will be months and months before it could be considered stable... > > > Frits Riep > > > > > _______________________________________________ > Cerowrt-devel mailing list > Cerowrt-devel@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/cerowrt-devel > --=20 Dave T=C3=A4ht NSFW: https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_= indecent.article