From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qc0-f181.google.com (mail-qc0-f181.google.com [209.85.216.181]) (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 2A84D21F31F for ; Wed, 21 May 2014 04:43:07 -0700 (PDT) Received: by mail-qc0-f181.google.com with SMTP id m20so2903722qcx.26 for ; Wed, 21 May 2014 04:43:06 -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:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :thread-index:content-language; bh=r660v+C4DgcglIeG3Abj+zztQDzaziv6+WhVQ4oJocU=; b=luwXa0fNlIG128v8R7b5G+ua0Se4t+dNLSnCB8AHplRFSvbV0DKRa4SZ7D0zbteudv NGqFkiQcQXu727tAcABm2MJiEf2HNe5g3piiT/TK6n6TqRCHGNsMcEhkN/IXHHiThkXk y5NwoxSX4GJDM2kpImBZTImM2vn28sNl0Ci7hekbqHiMz4odQXBJeNCH/7qrpYsZApBG o+yJu8kHQe+uz+KHhUBMenNYjlBHUYpZpM6CjjmBiveNhbFPHbvVGHjAqr3wLJ4y27vv NimQmiD0QWoULdHQWSvL/MBPDhSO/bpJF8TaN8fmUni2edqR/w8jCUpvQf/hVrB0WL4+ 5T0w== X-Gm-Message-State: ALoCoQmSwDFvNQmneTb9aTzBPScd+ttACMXU3Z60HbZsB2Mqb4yyvVDmiOVO5tPIXVxwb9Qdf/pi X-Received: by 10.140.35.212 with SMTP id n78mr64235320qgn.87.1400672585943; Wed, 21 May 2014 04:43:05 -0700 (PDT) Received: from RiepD630 (pool-108-49-217-37.bstnma.fios.verizon.net. [108.49.217.37]) by mx.google.com with ESMTPSA id w101sm581761qge.12.2014.05.21.04.43.05 for (version=TLSv1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 21 May 2014 04:43:05 -0700 (PDT) From: "Frits Riep" To: "'Dave Taht'" References: <006001cf7478$804951e0$80dbf5a0$@riepnet.com> In-Reply-To: Date: Wed, 21 May 2014 07:42:47 -0400 Message-ID: <006b01cf74e9$c9edf190$5dc9d4b0$@com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: Ac90gTGskFlVKxnvTjS8Y5mWRnhpRgAY1AIg Content-Language: en-us 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: Wed, 21 May 2014 11:43:07 -0000 Thanks Dave for your responses. Based on this, it is very good that = qos-scripts is available now through openwrt, and as I experienced, it = provides a huge advantage for most users. I would agree prioritizing = ping is in and of itself not the key goal, but based on what I've read = so far, fq-codel provides dramatically better responsiveness for any = interactive application such as web-browsing, voip, or gaming, so it = qos-scripts would be advantageous for users like your mom if she were in = an environment where she had a slow and shared internet connection. Is = that a valid interpretation? I am interested in further understanding = the differences based on the brief differences you provide. It is true = that few devices provide DSCP marking, but if the latency is controlled = for all traffic, latency sensitive traffic benefits tremendously even = without prioritizing by l7 (layer 7 ?). Is this interpretation also = valid? Yes, your mom wouldn't be a candidate for setting up ceroWRT herself, = but if it were set up for her, or if it could be incorporated into a = consumer router with automatically determining speed parameters, she = would benefit totally from the performance improvement. So the = technology ultimately needs to be taken mainstream, and yes that is a = huge task. Frits -----Original Message----- From: Dave Taht [mailto:dave.taht@gmail.com]=20 Sent: Tuesday, May 20, 2014 7:14 PM To: Frits Riep Cc: cerowrt-devel@lists.bufferbloat.net Subject: Re: [Cerowrt-devel] Ideas on how to simplify and popularize = bufferbloat control for consideration. On Tue, May 20, 2014 at 3:11 PM, Frits Riep wrote: > The concept of eliminating bufferbloat on many more routers is quite=20 > 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=20 > beyond the current Netgear. However, as good as some of the proposed=20 > platforms maybe for developing and for doing all of the new=20 > capabilities of CeroWRT, I also would like to propose that there also=20 > be some focus on reaching a wider and less sophisticated audience to=20 > help broaden the awareness and make control 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 = 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=20 > users with a much easier to install firmware release. I=E2=80=99d = like to be=20 > able to download luci-qos-scripts and sqm-scripts and have basic=20 > bufferbloat control on a much greater variety of devices and to many=20 > more users. From an awareness perspective this would be a huge win. =20 > Is the above scenario what 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 = available to > many users in a more affordable platform, something like an 8mb flash=20 > router like the TP-Link WDR-4300, which is otherwise a very capable=20 > router with dual channels and good performance. > > =C2=B7 (I=E2=80=99ve managed to set up such a WDR-4300, with = OpenWRT trunk, > figured how to telnet and install Luci, then luci-app-qos, and=20 > qos-scripts and I thought the bufferbloat control was remarkable.) =20 > How much better would it be if I were able to use luci-qos-scripts and = sqm-scripts instead? 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 = kernel 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 = dscp no framing compensation vs comprehensive framing compensation # win = here for 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 = performance, > ease of setup and affordability. They are not able to deal with the=20 > routing between subnets on wireless, IPv6 setup, and any complexities=20 > introduced by DNSSEC. Marketing the advantages of bufferbloat alone=20 > requires lots of education and publicity (and as we have seen there=20 > are many misleading posts by seemingly persuasive nay-sayers that it = is all smoke and mirrors. Well, my intent is to make the successful bits of technology widely = available. They are widely available. And being adopted everywhere. Win. As for the additional complexities, well, they will get less complex = over time. 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 = CeroWRT (in > terms of setup, and features), make It available for a reliable and=20 > affordable platform, and publicize it and have it reach hopefully a=20 > 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 state 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 = present 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 = funders 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 it sucks, and working to make that work well is not something I want = to be doing 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=20 > within the capabilities of the average weekend hacker, and there were=20 > 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,=20 > is still quite complex to someone who does not spend a lot of time=20 > 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 while. I'm presently planning on spending the summer working on something that = pays, 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 > -- Dave T=C3=A4ht NSFW: = https://w2.eff.org/Censorship/Internet_censorship_bills/russell_0296_inde= cent.article