From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp97.iad3a.emailsrvr.com (smtp97.iad3a.emailsrvr.com [173.203.187.97]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by huchra.bufferbloat.net (Postfix) with ESMTPS id BD2672021A8 for ; Wed, 21 May 2014 07:51:34 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 75F0D1280B2; Wed, 21 May 2014 10:51:33 -0400 (EDT) X-Virus-Scanned: OK Received: from app30.wa-webapps.iad3a (relay.iad3a.rsapps.net [172.27.255.110]) by smtp13.relay.iad3a.emailsrvr.com (SMTP Server) with ESMTP id 533E112808F; Wed, 21 May 2014 10:51:33 -0400 (EDT) Received: from reed.com (localhost.localdomain [127.0.0.1]) by app30.wa-webapps.iad3a (Postfix) with ESMTP id 3F81C80059; Wed, 21 May 2014 10:51:33 -0400 (EDT) Received: by apps.rackspace.com (Authenticated sender: dpreed@reed.com, from: dpreed@reed.com) with HTTP; Wed, 21 May 2014 10:51:33 -0400 (EDT) Date: Wed, 21 May 2014 10:51:33 -0400 (EDT) From: dpreed@reed.com To: "Frits Riep" MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_20140521105133000000_86896" Importance: Normal X-Priority: 3 (Normal) X-Type: html In-Reply-To: <006b01cf74e9$c9edf190$5dc9d4b0$@com> References: <006001cf7478$804951e0$80dbf5a0$@riepnet.com> <006b01cf74e9$c9edf190$5dc9d4b0$@com> Message-ID: <1400683893.25854395@apps.rackspace.com> X-Mailer: webmail7.0 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 14:51:35 -0000 ------=_20140521105133000000_86896 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =0ABesides deployment in cerowrt and openwrt, what would really have high l= everage is that the techniques developed in cerowrt's exploration (includin= g fq_codel) get deployed where they should be deployed: in the access netwo= rk systems: CMTS's, DSLAM's, Enterprise boundary gear, etc. from the major = players.=0A =0ACerowrt's fundamental focus has been proving that the techni= ques really, really work at scale.=0A =0AHowever, the fundamental "bloat-in= duced" experiences are actually occurring due to bloat at points where "fas= t meets slow". Cerowrt can't really fix the problem in the download direct= ion (currently not so bad because of high download speeds relative to uploa= d speeds in the US - that's in the CMTS's and DSLAM's.=0A =0AWhat's depress= ing to me is that the IETF community spends more time trying to convince th= emselves that bloat is only a theoretical problem, never encountered in the= field. In fact, every lab I've worked at (including the startup accelerat= or where some of my current company work) has had the network managers comp= laining to me that a single heavy FTP I'm running causes all of the other u= sers in the site to experience terrible web performance. But when they cal= l Cisco or F5 or whomever, they get told "there's nothing to do but buy com= plicated flow-based traffic management boxes to stick in line with the traf= fic (so they can "slow me down").=0A =0ABloat is the most common invisible = elephant on the Internet. Just fixing a few access points is a start, but = even if we fix all the access points so that uploads interfere less, there'= s still more impact this one thing can have.=0A =0ASo, by all means get thi= s stuff into mainstream, but it's time to start pushing on the access netwo= rk technology companies (and there are now open switches from Cumulus and e= ven Arista to hack)=0A =0A=0A=0AOn Wednesday, May 21, 2014 7:42am, "Frits R= iep" said:=0A=0A=0A=0A> Thanks Dave for your responses. = Based on this, it is very good that qos-scripts=0A> is available now throu= gh openwrt, and as I experienced, it provides a huge=0A> advantage for most= users. I would agree prioritizing ping is in and of itself not=0A> the ke= y goal, but based on what I've read so far, fq-codel provides dramatically= =0A> better responsiveness for any interactive application such as web-brow= sing, voip,=0A> or gaming, so it qos-scripts would be advantageous for user= s like your mom if she=0A> were in an environment where she had a slow and = shared internet connection. Is=0A> that a valid interpretation? I am inte= rested in further understanding the=0A> differences based on the brief diff= erences you provide. It is true that few=0A> devices provide DSCP marking,= but if the latency is controlled for all traffic,=0A> latency sensitive tr= affic benefits tremendously even without prioritizing by l7=0A> (layer 7 ?)= . Is this interpretation also valid?=0A> =0A> Yes, your mom wouldn't be a c= andidate for setting up ceroWRT herself, but if it=0A> were set up for her,= or if it could be incorporated into a consumer router with=0A> automatical= ly determining speed parameters, she would benefit totally from the=0A> per= formance improvement. So the technology ultimately needs to be taken=0A> m= ainstream, and yes that is a huge task.=0A> =0A> Frits=0A> =0A> -----Origin= al Message-----=0A> From: Dave Taht [mailto:dave.taht@gmail.com]=0A> Sent: = Tuesday, May 20, 2014 7:14 PM=0A> To: Frits Riep=0A> Cc: cerowrt-devel@list= s.bufferbloat.net=0A> Subject: Re: [Cerowrt-devel] Ideas on how to simplify= and popularize bufferbloat=0A> control for consideration.=0A> =0A> On Tue,= May 20, 2014 at 3:11 PM, Frits Riep wrote:=0A> > The co= ncept of eliminating bufferbloat on many more routers is quite=0A> > appeal= ing. Reading some of the recent posts makes it clear there is a=0A> > desi= re to get to a stable code, and also to find a new platform=0A> > beyond t= he current Netgear. However, as good as some of the proposed=0A> > platfor= ms maybe for developing and for doing all of the new=0A> > capabilities of = CeroWRT, I also would like to propose that there also=0A> > be some focus o= n reaching a wider and less sophisticated audience to=0A> > help broaden th= e awareness and make control of bufferbloat more available and=0A> easier t= o attain for more users.=0A> =0A> I agree that reaching more users is impor= tant. I disagree we need to reach them=0A> with cerowrt. More below:=0A> = =0A> >=0A> >=0A> > =C2=B7 It appears there is a desire to merge the= code into an=0A> upcoming=0A> > OpenWRT barrier breaker release, which is = excellent as it will make it=0A> > easier to fight buffer bloat on a wide r= ange of platforms and provide=0A> > users with a much easier to install fir= mware release. I=E2=80=99d like to be=0A> > able to download luci-qos-scri= pts and sqm-scripts and have basic=0A> > bufferbloat control on a much grea= ter variety of devices and to many=0A> > more users. From an awareness per= spective this would be a huge win.=0A> > Is the above scenario what is bein= g planned, is it likely to happen in the=0A> reasonable future?=0A> =0A> Ye= s, I'd submitted sqm for review upstream, got back a few comments. Intend t= o=0A> resubmit again when I get a chance.=0A> =0A> >=0A> > =C2=B7 F= rom my perspective, it would be ideal to have this=0A> available to=0A> > m= any users in a more affordable platform, something like an 8mb flash=0A> > = router like the TP-Link WDR-4300, which is otherwise a very capable=0A> > r= outer with dual channels and good performance.=0A> >=0A> > =C2=B7 (= I=E2=80=99ve managed to set up such a WDR-4300, with OpenWRT=0A> trunk,=0A>= > figured how to telnet and install Luci, then luci-app-qos, and=0A> > qos= -scripts and I thought the bufferbloat control was remarkable.)=0A> > How m= uch better would it be if I were able to use luci-qos-scripts and=0A> sqm-s= cripts instead?=0A> =0A> You can easily add the .ipk files for sqm-scripts = and luci-app-sqm to any release=0A> of openwrt. They are just scripts. They= need some optional kernel modules and=0A> tools.=0A> =0A> I regard the qos= -scripts as pretty good - the core differences from sqm are=0A> =0A> qos v= s sqm=0A> ---------------=0A> both use fq_codel. :)=0A> hfsc vs htb # A was= h, hfsc mostly behaves like htb ping optimized vs de-optimized=0A> # optimi= zing for ping looks good in benchmarks but it's silly in the real world=0A>= (l7) classification vs dscp # clear win to qos here, nearly nothing uses d= scp no=0A> framing compensation vs comprehensive framing compensation # win= here for sqm no=0A> alternate queue models vs many alternate queue models = # with fq_codel the winner,=0A> who cares?=0A> fits in 4mb flash vs barely = fits in 4mb flash=0A> =0A> The real killer problem for qos-scripts, for me,= was that they didn't do ipv6. I'd=0A> like to see that fixed, at the very = least.=0A> =0A> =0A> >=0A> > =C2=B7 For these target users, they ne= ed simplicity, good=0A> performance,=0A> > ease of setup and affordability.= They are not able to deal with the=0A> > routing between subnets on wirel= ess, IPv6 setup, and any complexities=0A> > introduced by DNSSEC. Marketin= g the advantages of bufferbloat alone=0A> > requires lots of education and= publicity (and as we have seen there=0A> > are many misleading posts by se= emingly persuasive nay-sayers that it is all=0A> smoke and mirrors.=0A> =0A= > Well, my intent is to make the successful bits of technology widely avail= able.=0A> They are widely available. And being adopted everywhere. Win.=0A>= =0A> As for the additional complexities, well, they will get less complex = over time.=0A> =0A> In one respect, they are a stake in the ground. I have = high hopes for the eventual=0A> success of hnetd and mdns proxy services, a= lthough they are alpha and nearly=0A> unusable right now, some are making s= ubstantial investments into them.=0A> =0A> In another the additional comple= xities of cero - like routing vs bridging - are=0A> there to further the re= search into fixing wifi technologies - which we haven't=0A> really even sta= rted yet. I'm increasingly convinced we need to do make-wifi-fast=0A> as a = separate, focused project, building on a stable base.=0A> =0A> > =C2=B7 = Would it be possible to have a simplified release of CeroWRT=0A> (in= =0A> > terms of setup, and features), make It available for a reliable and= =0A> > affordable platform, and publicize it and have it reach hopefully a= =0A> > much wider audience? This could potentially be through the OpenWRT = channels.=0A> =0A> Possible yes. Affordable, no. Given that this has been a= nearly full time project=0A> for me, for the last 38 months, with nearly z= ero revenue, I have no intent or=0A> interest in gaining anything other tha= n knowledgable, clued users that want to=0A> advance the state of the art. = My mom doesn't run cerowrt, nor do I want her to.=0A> =0A> If someone dropp= ed ~1m/year on the project, that could change, but at present=0A> levels of= funding I'd be better off working at mcdonalds. Even if funding appeared= =0A> from the sky I'd rather spend it on R&D than GUI...=0A> =0A> Certainly= IF there was some cost model that made sense, awesome! let's go for=0A> wo= rld domination!=0A> =0A> I continue to pursue the grant=0A> route, but the = only thing that resonates even slightly with potential funders is=0A> not s= peed but security issues, which give me nightmares. Another model that work= s=0A> is actually making and selling a router, but that requires up front c= apital and=0A> entry into a very tight, profit-limited market.=0A> =0A> Big= gest problem we have is supporting ONLY one router, even-semi-well, is a PI= TA.=0A> =0A> Adding a new one costs more. I'm now on my 4th day of trying t= o make the archer=0A> work. That's 6k of my life I'll never have back. And = the ath10k in it sucks, and=0A> working to make that work well is not somet= hing I want to be doing due to the=0A> binary blob wifi firmware.=0A> =0A> = I'm all in favor of handing off future cerowrt development to a nonprofit o= f=0A> interested users, and sitting back and focusing on fixing just the bi= ts I care=0A> about, if anyone is interested in forming one...=0A> =0A> > = =C2=B7 Part of the reason why Tomato had been so popular is that=0A= > the=0A> > firmware upgrade, install, configuration, and management was w= ell=0A> > within the capabilities of the average weekend hacker, and there = were=0A> > compelling features and reliability vs the factory firmwares at = the time.=0A> =0A> Yep. dd-wrt is the same. And various downstream users li= ke buffalo, meraki etc.=0A> =0A> I'm totally happy that they exist and have= a working market.=0A> =0A> > =C2=B7 Even installing OpenWRT, espec= ially Trunk, and finding,=0A> > downloading and enabling packages, while ve= ry powerful, and flexible,=0A> > is still quite complex to someone who does= not spend a lot of time=0A> > reading wiki=E2=80=99s and release notes.=0A= > =0A> Yes, CeroWrt is an improvement on OpenWrt in that regard. But it isn= 't enough.=0A> Doing serious UI improvements and simplification IS necessar= y, and that's not my=0A> bag. The EFF is making noises about doing somethin= g with the front end of openwrt=0A> and/or cero in the next year or so (see= their owtech list for more details), that=0A> also goes after the security= issue.=0A> =0A> > I=E2=80=99d be interested in feedback on these thoughts.= =0A> =0A> There you go. I LOVE that we have a happy userbase, and love what= we've=0A> accomplished, and have loved being here to help make it happen, = and love that lots=0A> of people want to get it more out there to more peop= le, it's gratifying as hell,=0A> and there are a lot of negatives too, like= chasing bugs for months on end...=0A> =0A> ... but after we freeze, I need= a vacation and to do something else for a while.=0A> =0A> I'm presently pl= anning on spending the summer working on something that pays, and=0A> on im= proving ns3 with the GSOC, and testing a deployment of cerowrts on a modest= =0A> scale, and working on a new/improved rate limiter integrated with fq_c= odel. And=0A> only updating cero for CVEs or major new features.=0A> =0A> = That's a full plate.=0A> =0A> If someone else wants to step up to maintain = or continue to push cerowrt forward=0A> in some direction or another, I'm a= ll for it.=0A> =0A> It's kind of my hope a clear winner on the chipset fron= t will emerge and we can=0A> move to that, but even if that happens it will= be months and months before it=0A> could be considered stable...=0A> =0A> = =0A> =0A> >=0A> >=0A> > Frits Riep=0A> >=0A> >=0A> >=0A> >=0A> > __________= _____________________________________=0A> > Cerowrt-devel mailing list=0A> = > Cerowrt-devel@lists.bufferbloat.net=0A> > https://lists.bufferbloat.net/l= istinfo/cerowrt-devel=0A> >=0A> =0A> =0A> =0A> --=0A> Dave T=C3=A4ht=0A> = =0A> NSFW:=0A> https://w2.eff.org/Censorship/Internet_censorship_bills/russ= ell_0296_indecent.article=0A> =0A> ________________________________________= _______=0A> Cerowrt-devel mailing list=0A> Cerowrt-devel@lists.bufferbloat.= net=0A> https://lists.bufferbloat.net/listinfo/cerowrt-devel=0A> ------=_20140521105133000000_86896 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Besides de= ployment in cerowrt and openwrt, what would really have high leverage is th= at the techniques developed in cerowrt's exploration (including fq_codel) g= et deployed where they should be deployed: in the access network systems: C= MTS's, DSLAM's, Enterprise boundary gear, etc. from the major players.

= =0A

 

=0A

Cerowrt's fundamental focus has been proving that the techniques rea= lly, really work at scale.

=0A

 =0A

However, the fundamental "bloat-induce= d" experiences are actually occurring due to bloat at points where "fast me= ets slow".  Cerowrt can't really fix the problem in the download direc= tion (currently not so bad because of high download speeds relative to uplo= ad speeds in the US - that's in the CMTS's and DSLAM's.

=0A

 

=0A

What's de= pressing to me is that the IETF community spends more time trying to convin= ce themselves that bloat is only a theoretical problem, never encountered i= n the field.  In fact, every lab I've worked at (including the startup= accelerator where some of my current company work) has had the network man= agers complaining to me that a single heavy FTP I'm running causes all of t= he other users in the site to experience terrible web performance.  Bu= t when they call Cisco or F5 or whomever, they get told "there's nothing to= do but buy complicated flow-based traffic management boxes to stick in lin= e with the traffic (so they can "slow me down").

=0A

 

=0A

Bloat is the mos= t common invisible elephant on the Internet.  Just fixing a few access= points is a start, but even if we fix all the access points so that upload= s interfere less, there's still more impact this one thing can have.

=0A=

 

=0A

So, by all means get this stuff into mainstream, but it's time to start= pushing on the access network technology companies (and there are now open= switches from Cumulus and even Arista to hack)

=0A

 

=0A




On Wednesday, May 21, 2014 7:42am, "Frits Riep" <riep@riepnet.com>= ; said:

=0A
=0A

> 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 ke= y goal, but based on what I've read so far, fq-codel provides dramatically<= br />> better responsiveness for any interactive application such as web= -browsing, voip,
> or gaming, so it qos-scripts would be advantageo= us for users like your mom if she
> were in an environment where sh= e had a slow and shared internet connection. Is
> that a valid int= erpretation? I am interested in further understanding the
> differ= ences based on the brief differences you provide. It is true that few
> devices provide DSCP marking, but if the latency is controlled for al= l traffic,
> latency sensitive traffic benefits tremendously even w= ithout prioritizing by l7
> (layer 7 ?). Is this interpretation als= o valid?
>
> Yes, your mom wouldn't be a candidate for set= ting up ceroWRT herself, but if it
> were set up for her, or if it = could be incorporated into a consumer router with
> automatically d= etermining speed parameters, she would benefit totally from the
> p= erformance improvement. So the technology ultimately needs to be taken
> mainstream, and yes that is a huge task.
>
> Frits<= br />>
> -----Original Message-----
> From: Dave Taht [= mailto:dave.taht@gmail.com]
> 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 populari= ze bufferbloat
> control for consideration.
>
> On= Tue, May 20, 2014 at 3:11 PM, Frits Riep <riep@riepnet.com> wrote:> > The concept of eliminating bufferbloat on many more routers i= s quite
> > appealing. Reading some of the recent posts makes i= t 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 develo= ping 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 br= oaden the awareness and make control of bufferbloat more available and
> easier to attain for more users.
>
> I agree that re= aching 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 a= n
> 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=E2=80=99d 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 hu= ge win.
> > Is the above scenario what is being planned, is it l= ikely to happen in the
> reasonable future?
>
> Ye= s, I'd submitted sqm for review upstream, got back a few comments. Intend t= o
> 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
> > router like the TP-Li= nk WDR-4300, which is otherwise a very capable
> > router with d= ual 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-a= pp-qos, and
> > qos-scripts and I thought the bufferbloat contro= l was remarkable.)
> > How much better would it be if I were abl= e to use luci-qos-scripts and
> sqm-scripts instead?
>
> You can easily add the .ipk files for sqm-scripts and luci-app-sqm t= o any release
> of openwrt. They are just scripts. They need some o= ptional kernel modules and
> tools.
>
> I regard t= he qos-scripts as pretty good - the core differences from sqm are
>=
> qos vs sqm
> ---------------
> both use fq_cod= el. :)
> hfsc vs htb # A wash, hfsc mostly behaves like htb ping op= timized vs de-optimized
> # optimizing for ping looks good in bench= marks but it's silly in the real world
> (l7) classification vs dsc= p # clear win to qos here, nearly nothing uses dscp no
> framing co= mpensation 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 fit= s 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 fixe= d, 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
> > routing between subnets on wireless, = IPv6 setup, and any complexities
> > introduced by DNSSEC. Mark= eting 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.
>
> Well, my intent is to make the su= ccessful bits of technology widely available.
> They are widely ava= ilable. And being adopted everywhere. Win.
>
> As for the = additional complexities, well, they will get less complex over time.
&= gt;
> 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 m= aking substantial investments into them.
>
> In another th= e additional complexities of cero - like routing vs bridging - are
>= ; there to further the research into fixing wifi technologies - which we ha= ven'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 possib= le to have a simplified release of CeroWRT
> (in
> > ter= ms 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 Op= enWRT channels.
>
> Possible yes. Affordable, no. Given th= at 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 wa= nt her to.
>
> If someone dropped ~1m/year on the project,= that could change, but at present
> levels of funding I'd be bette= r 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
&g= t; world domination!
>
> I continue to pursue the grant> route, but the only thing that resonates even slightly with potenti= al funders is
> not speed but security issues, which give me nightm= ares. Another model that works
> is actually making and selling a r= outer, but that requires up front capital and
> entry into a very t= ight, profit-limited market.
>
> Biggest problem we have i= s supporting ONLY one router, even-semi-well, is a PITA.
>
&g= t; 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 som= ething I want to be doing due to the
> binary blob wifi firmware.>
> I'm all in favor of handing off future cerowrt developm= ent to a nonprofit of
> interested users, and sitting back and focu= sing on fixing just the bits I care
> about, if anyone is intereste= d in forming one...
>
> > =C2=B7 Part of the re= ason why Tomato had been so popular is that
> the
> > fi= rmware upgrade, install, configuration, and management was well
> = > within the capabilities of the average weekend hacker, and there were<= br />> > compelling features and reliability vs the factory firmwares= at the time.
>
> Yep. dd-wrt is the same. And various dow= nstream users like buffalo, meraki etc.
>
> I'm totally ha= ppy 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 flex= ible,
> > 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. B= ut it isn't enough.
> Doing serious UI improvements and simplificat= ion 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.
>
> Ther= e you go. I LOVE that we have a happy userbase, and love what we've
&g= t; 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 w= e freeze, I need a vacation and to do something else for a while.
>=
> I'm presently planning on spending the summer working on someth= ing that pays, and
> on improving ns3 with the GSOC, and testing a = deployment of cerowrts on a modest
> scale, and working on a new/im= proved rate limiter integrated with fq_codel. And
> only updating = cero for CVEs or major new features.
>
> That's a full pla= te.
>
> If someone else wants to step up to maintain or co= ntinue 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 t= hat happens it will be months and months before it
> could be consi= dered stable...
>
>
>
> >
> &= gt;
> > Frits Riep
> >
> >
> ><= br />> >
> > _____________________________________________= __
> > Cerowrt-devel mailing list
> > Cerowrt-devel@l= ists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/= cerowrt-devel
> >
>
>
>
> --<= br />> Dave T=C3=A4ht
>
> NSFW:
> https://w2.ef= f.org/Censorship/Internet_censorship_bills/russell_0296_indecent.article>
> _______________________________________________
>= ; Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net<= br />> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>=0A

 ------=_20140521105133000000_86896--