Re: [Bloat] How to "sell" improvement
On 28/11/16 02:26 PM, Jonathan Morton wrote: On 28 Nov, 2016, at 20:37, David Collier-Brownwrote: I'm using latency as the time from the request to the first response transfer time as the time from the first response to the last response, which may be 0, and sleep/think time as the time from the last response to the next request, for a given stream of requests and responses, AKA "transactions" This is a useful set of definitions, though I would quibble that “transfer time” should also be measured from the request, not from the first response. Latency + Transfer Time add up to make "Response Time", which is from very beginning to very end, as you note. A more complete picture would add a measure of application-induced delay, which is visible to the user but not necessarily to the network. It is influenced mainly by the end host's performance, not by anything in the network, and would presumably count as part of the “think time” for many applications. Hence it’s not relevant for *our* objectives, but might be to others. The response also breaks down into queue delay and service time, which don't line up with the latency/transfer split. Service time is the time a warm system takes to process one request-response pair, while delay is the time spent waiting for the cache to load, stuff get read from disk and, especially especially, the time sitting in the run-queue, twiddling your thumbs, waiting for a CPU. Those aren't easily measured from outside the system, although I've approximated them with a stepping load test. They're easy to measure in-app, though. Incidentally, did anyone notice that Intel revived their old “optimised for the Internet” marketing fluff for their new Kaby Lake CPUs? Last seen for the Pentium III, and just as disingenuous. - Jonathan Morton "Intel inside" is a warning label (;-)) --dave -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest dav...@spamcop.net | -- Mark Twain ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] How to "sell" improvement
On Mon, 28 Nov 2016, David Collier-Brown wrote: Yes, especially for * the performance-reporting tools' own page and also for * some well-known, moderately complex ones. Not the minimalist Google front page, but perhaps a particular query... First off, can we get people to nominate candidate pages? Then, let's see if we can make a simulator for that page, so the test won't break when the website gets updated, something that has the same serialization issues hitting multiple sites and fetching a bunch of items of various sizes (ideally, but not neccessarily involving slight delays on the server before returning the objexts) turn this test into a apache module so it's easy to use and isn't affected by system variations (and eliminates possible security risks by having the module not access anything on the system) Then get this deployed a bunch of places. David Lang___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] How to "sell" improvement
> On 28 Nov, 2016, at 20:37, David Collier-Brownwrote: > > I'm using latency as the time from the request to the first response > transfer time as the time from the first response to the last response, which > may be 0, and > sleep/think time as the time from the last response to the next request, for > a given stream of requests and responses, AKA "transactions" This is a useful set of definitions, though I would quibble that “transfer time” should also be measured from the request, not from the first response. A more complete picture would add a measure of application-induced delay, which is visible to the user but not necessarily to the network. It is influenced mainly by the end host's performance, not by anything in the network, and would presumably count as part of the “think time” for many applications. Hence it’s not relevant for *our* objectives, but might be to others. Incidentally, did anyone notice that Intel revived their old “optimised for the Internet” marketing fluff for their new Kaby Lake CPUs? Last seen for the Pentium III, and just as disingenuous. - Jonathan Morton ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] How to "sell" improvement
Yes, especially for * the performance-reporting tools' own page and also for * some well-known, moderately complex ones. Not the minimalist Google front page, but perhaps a particular query... --dave On 28/11/16 01:58 PM, Simon Barber wrote: Web page load time. Simon On Nov 28, 2016, at 10:37 AM, David Collier-Brownwrote: In this context, I'd say latency and the effect of bloat reduction on it and transfer time. Dave Taht can say much more (;-)) I'm just echoing his concern, from the point of view of a capacity planner. --dave c-b [I'm using latency as the time from the request to the first response, transfer time as the time from the first response to the last response, which may be 0, and sleep/think time as the time from the last response to the next request, for a given stream of requests and responses, AKA "transactions"] On 28/11/16 12:59 PM, Kathleen Nichols wrote: That's a good idea in general, but what are you measuring for your "actual performance"? Raw throughput? Goodput (which requires a bit of processing)? Then what about delay? On 11/28/16 9:41 AM, David Collier-Brown wrote: Put the speed-test /into the router/, with a big red button to turn fq_codel on and off. * The performance reporting graphs can then run on a browser page for as long as you like, while you do other things, and go back to the page and see what it's been like. * Have a line for "perfect" performance, and anyone can see how close you're system is coming to it. * Have a button for a synthetic load test, of some shortish duration, and, * Put it on normal Linux hosts too, so you can test end-to-end. This has the advantage that it's code-first, so you don't have to convince the uninterested, and from it you can write a small and limited RFC to tell everyone else how you did it. As each new improvement comes along, actual performance slowly gets closer and closer to the optimal performance line... --dave On 28/11/16 10:21 AM, Jonathan Foulkes wrote: Thanks for the Introduction Rich, and thanks again to you and many others on this list for all your contributions over the years helping to combat bloat. This product was born of my own frustration with finding a way to help neighbors and family get a simple off-the-shelf solution that even non-technical users can deploy. I look forward to participating more actively on this list. Jonathan On Nov 26, 2016, at 9:08 AM, Rich Brown wrote: I have been exchanging a few emails with Jonathan Foulkes from evenroute.com. He tells me that his company is installing OpenWrt on a commercial, off the shelf (COTS) TP-Link router and selling them on commercially. His "secret sauce" is an auto-update facility and improved setup software, which includes a rate-detection step that operates continually to adjust the fq_codel parameters to the actual line rate. You can take a look at IQrouter.com, or look them up on Amazon. This might be a solution to our current conundrum about not having an easy solution that solves our family's networking problem. I'm going to get one of these and try it out. He has been following our bufferbloat and make-fifi-fast work closely, as well as the work on LEDE, which he'll consider once it hits a stable point. I have invited him to join this list. Welcome, Jonathan. ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest dav...@spamcop.net | -- Mark Twain ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest dav...@spamcop.net | -- Mark Twain ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest dav...@spamcop.net | -- Mark Twain ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Fixing bufferbloat in 2017
> On 28 Nov, 2016, at 19:07, Dave Tahtwrote: > > (as well as VR ones) VR gaming *is* pretty hot right now. Even the consoles are trying to get in on it, though I’m skeptical if even the just-upgraded consoles have the horsepower to really keep up. The big thing about VR is that latency and framerate matter about 100x more than they do with a normal, 2D-projected game, because the realism factor is stepped up by using “natural” movements to control viewpoint and aimpoint instead of interpolating a mouse and keyboard. Most of the (reputable) VR headset guys recommend a solid 90fps and absolutely minimal input-to-display lag to avoid motion sickness. To put that into perspective, most monitors on peoples’ desks right now top out at 60Hz, and the equivalent responsiveness of a “fairly good” Internet connection is 20-30Hz. Fortunately, the latter mostly impacts the movements of other objects in the game world, not the player himself - but there are counterexamples, especially in competitive multiplayer games. I’m still keen on representing network latency as its reciprocal, “responsiveness”, which carries the same unit as framerate and is thereby made intuitively intelligible to gaming enthusiasts. Admittedly most multiplayer gamers are by now familiar with “ping” in milliseconds, but they probably haven’t done the arithmetic to relate it to framerate and thus understand its relative importance. - Jonathan Morton ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] How to "sell" improvement
Web page load time. Simon > On Nov 28, 2016, at 10:37 AM, David Collier-Brownwrote: > > In this context, I'd say latency and the effect of bloat reduction on it and > transfer time. > > Dave Taht can say much more (;-)) > I'm just echoing his concern, from the point of view of a capacity planner. > > --dave c-b > [I'm using latency as the time from the request to the first response, > transfer time as the time from the first response to the last response, which > may be 0, and sleep/think time as the time from the last response to the next > request, for a given stream of requests and responses, AKA "transactions"] > > > On 28/11/16 12:59 PM, Kathleen Nichols wrote: >> That's a good idea in general, but what are you measuring for your >> "actual performance"? >> Raw throughput? Goodput (which requires a bit of processing)? Then what >> about delay? >> >> On 11/28/16 9:41 AM, David Collier-Brown wrote: >>> Put the speed-test /into the router/, with a big red button to turn >>> fq_codel on and off. >>> >>> * The performance reporting graphs can then run on a browser page >>> for as long as you like, while you do other things, and go back to >>> the page and see what it's been like. * Have a line for "perfect" >>> performance, and anyone can see how close you're system is coming to >>> it. * Have a button for a synthetic load test, of some shortish >>> duration, and, * Put it on normal Linux hosts too, so you can test >>> end-to-end. >>> >>> >>> This has the advantage that it's code-first, so you don't have to >>> convince the uninterested, and from it you can write a small and >>> limited RFC to tell everyone else how you did it. >>> >>> As each new improvement comes along, actual performance slowly gets >>> closer and closer to the optimal performance line... >>> >>> --dave >>> >>> >>> On 28/11/16 10:21 AM, Jonathan Foulkes wrote: Thanks for the Introduction Rich, and thanks again to you and many others on this list for all your contributions over the years helping to combat bloat. This product was born of my own frustration with finding a way to help neighbors and family get a simple off-the-shelf solution that even non-technical users can deploy. I look forward to participating more actively on this list. Jonathan > On Nov 26, 2016, at 9:08 AM, Rich Brown > wrote: > > I have been exchanging a few emails with Jonathan Foulkes from > evenroute.com. He tells me that his company is installing OpenWrt > on a commercial, off the shelf (COTS) TP-Link router and selling > them on commercially. His "secret sauce" is an auto-update > facility and improved setup software, which includes a > rate-detection step that operates continually to adjust the > fq_codel parameters to the actual line rate. You can take a look > at IQrouter.com, or look them up on Amazon. > > This might be a solution to our current conundrum about not > having an easy solution that solves our family's networking > problem. I'm going to get one of these and try it out. > > He has been following our bufferbloat and make-fifi-fast work > closely, as well as the work on LEDE, which he'll consider once > it hits a stable point. I have invited him to join this list. > > Welcome, Jonathan. > > ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat >>> >>> -- David Collier-Brown, | Always do right. This will gratify >>> System Programmer and Author | some people and astonish the rest >>> dav...@spamcop.net | -- Mark Twain >>> >>> >>> >>> ___ Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >>> >> ___ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat > > > -- > David Collier-Brown, | Always do right. This will gratify > System Programmer and Author | some people and astonish the rest > dav...@spamcop.net | -- Mark Twain > > ___ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] How to "sell" improvement
In this context, I'd say latency and the effect of bloat reduction on it and transfer time. Dave Taht can say much more (;-)) I'm just echoing his concern, from the point of view of a capacity planner. --dave c-b [I'm using latency as the time from the request to the first response, transfer time as the time from the first response to the last response, which may be 0, and sleep/think time as the time from the last response to the next request, for a given stream of requests and responses, AKA "transactions"] On 28/11/16 12:59 PM, Kathleen Nichols wrote: That's a good idea in general, but what are you measuring for your "actual performance"? Raw throughput? Goodput (which requires a bit of processing)? Then what about delay? On 11/28/16 9:41 AM, David Collier-Brown wrote: Put the speed-test /into the router/, with a big red button to turn fq_codel on and off. * The performance reporting graphs can then run on a browser page for as long as you like, while you do other things, and go back to the page and see what it's been like. * Have a line for "perfect" performance, and anyone can see how close you're system is coming to it. * Have a button for a synthetic load test, of some shortish duration, and, * Put it on normal Linux hosts too, so you can test end-to-end. This has the advantage that it's code-first, so you don't have to convince the uninterested, and from it you can write a small and limited RFC to tell everyone else how you did it. As each new improvement comes along, actual performance slowly gets closer and closer to the optimal performance line... --dave On 28/11/16 10:21 AM, Jonathan Foulkes wrote: Thanks for the Introduction Rich, and thanks again to you and many others on this list for all your contributions over the years helping to combat bloat. This product was born of my own frustration with finding a way to help neighbors and family get a simple off-the-shelf solution that even non-technical users can deploy. I look forward to participating more actively on this list. Jonathan On Nov 26, 2016, at 9:08 AM, Rich Brownwrote: I have been exchanging a few emails with Jonathan Foulkes from evenroute.com. He tells me that his company is installing OpenWrt on a commercial, off the shelf (COTS) TP-Link router and selling them on commercially. His "secret sauce" is an auto-update facility and improved setup software, which includes a rate-detection step that operates continually to adjust the fq_codel parameters to the actual line rate. You can take a look at IQrouter.com, or look them up on Amazon. This might be a solution to our current conundrum about not having an easy solution that solves our family's networking problem. I'm going to get one of these and try it out. He has been following our bufferbloat and make-fifi-fast work closely, as well as the work on LEDE, which he'll consider once it hits a stable point. I have invited him to join this list. Welcome, Jonathan. ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest dav...@spamcop.net | -- Mark Twain ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest dav...@spamcop.net | -- Mark Twain ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] How to "sell" improvement
That's a good idea in general, but what are you measuring for your "actual performance"? Raw throughput? Goodput (which requires a bit of processing)? Then what about delay? On 11/28/16 9:41 AM, David Collier-Brown wrote: > Put the speed-test /into the router/, with a big red button to turn > fq_codel on and off. > > * The performance reporting graphs can then run on a browser page > for as long as you like, while you do other things, and go back to > the page and see what it's been like. * Have a line for "perfect" > performance, and anyone can see how close you're system is coming to > it. * Have a button for a synthetic load test, of some shortish > duration, and, * Put it on normal Linux hosts too, so you can test > end-to-end. > > > This has the advantage that it's code-first, so you don't have to > convince the uninterested, and from it you can write a small and > limited RFC to tell everyone else how you did it. > > As each new improvement comes along, actual performance slowly gets > closer and closer to the optimal performance line... > > --dave > > > On 28/11/16 10:21 AM, Jonathan Foulkes wrote: >> Thanks for the Introduction Rich, and thanks again to you and many >> others on this list for all your contributions over the years >> helping to combat bloat. >> >> This product was born of my own frustration with finding a way to >> help neighbors and family get a simple off-the-shelf solution that >> even non-technical users can deploy. >> >> I look forward to participating more actively on this list. >> >> Jonathan >> >>> On Nov 26, 2016, at 9:08 AM, Rich Brown>>> wrote: >>> >>> I have been exchanging a few emails with Jonathan Foulkes from >>> evenroute.com. He tells me that his company is installing OpenWrt >>> on a commercial, off the shelf (COTS) TP-Link router and selling >>> them on commercially. His "secret sauce" is an auto-update >>> facility and improved setup software, which includes a >>> rate-detection step that operates continually to adjust the >>> fq_codel parameters to the actual line rate. You can take a look >>> at IQrouter.com, or look them up on Amazon. >>> >>> This might be a solution to our current conundrum about not >>> having an easy solution that solves our family's networking >>> problem. I'm going to get one of these and try it out. >>> >>> He has been following our bufferbloat and make-fifi-fast work >>> closely, as well as the work on LEDE, which he'll consider once >>> it hits a stable point. I have invited him to join this list. >>> >>> Welcome, Jonathan. >>> >>> >> ___ Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat > > > -- David Collier-Brown, | Always do right. This will gratify > System Programmer and Author | some people and astonish the rest > dav...@spamcop.net | -- Mark Twain > > > > ___ Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Fixing bufferbloat in 2017
Well, it would be good to know where the congestion is coming from, i.e. saying that "the network is congested" doesn't say which network. Since our downlink got upgraded, there is rarely an issue there but from time to time the comcast network just "goes down" in that it seems that nothing gets out (the Nextdoor list then pops up all these postings "is anyone else having internet problems?") but this is infrequent. We've been able to find all sorts of interesting things in the home network including some substandard cabling (which has been replaced) and various wifi oddities (which would be easier to characterize if I could get better data on the clients, particularly wrt to Google wifi but I have an idea on this) Guess if your house is on fire, you stop watching the cat videos, right? Kathie On 11/28/16 8:58 AM, Stephen Hemminger wrote: > My experience has been that the media and developer attention span is > short lived, and maybe that is part of the problem. Gaming is a niche > market, and therefore is easily ignored; plus the classic gaming > market is dying and I am not sure anyone is really investing in it. > > The current hot topic use case seems to be machine learning and voice > interaction. I wonder if we could build a use case something related > to that? "Ok Google, my house is on fire!!" -- "Sorry can not call > fire department, network is congested". > > > ___ Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
[Bloat] How to "sell" improvement (was: COTS router with OpenWrt)
Put the speed-test /into the router/, with a big red button to turn fq_codel on and off. * The performance reporting graphs can then run on a browser page for as long as you like, while you do other things, and go back to the page and see what it's been like. * Have a line for "perfect" performance, and anyone can see how close you're system is coming to it. * Have a button for a synthetic load test, of some shortish duration, and, * Put it on normal Linux hosts too, so you can test end-to-end. This has the advantage that it's code-first, so you don't have to convince the uninterested, and from it you can write a small and limited RFC to tell everyone else how you did it. As each new improvement comes along, actual performance slowly gets closer and closer to the optimal performance line... --dave On 28/11/16 10:21 AM, Jonathan Foulkes wrote: Thanks for the Introduction Rich, and thanks again to you and many others on this list for all your contributions over the years helping to combat bloat. This product was born of my own frustration with finding a way to help neighbors and family get a simple off-the-shelf solution that even non-technical users can deploy. I look forward to participating more actively on this list. Jonathan On Nov 26, 2016, at 9:08 AM, Rich Brownwrote: I have been exchanging a few emails with Jonathan Foulkes from evenroute.com. He tells me that his company is installing OpenWrt on a commercial, off the shelf (COTS) TP-Link router and selling them on commercially. His "secret sauce" is an auto-update facility and improved setup software, which includes a rate-detection step that operates continually to adjust the fq_codel parameters to the actual line rate. You can take a look at IQrouter.com, or look them up on Amazon. This might be a solution to our current conundrum about not having an easy solution that solves our family's networking problem. I'm going to get one of these and try it out. He has been following our bufferbloat and make-fifi-fast work closely, as well as the work on LEDE, which he'll consider once it hits a stable point. I have invited him to join this list. Welcome, Jonathan. ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest dav...@spamcop.net | -- Mark Twain ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] COTS router with OpenWrt
Jonathan Foulkeswrites: > Hi Dave, a special thanks to you for all the cheerleading and pushing you do > on this topic. > >> I hope that your marketing campaign is being successful on these >> fronts. It has always been my goal to "enable better products", but >> not have the headache of making them myself, where 99.99% of the >> effort is (like in cerowrt), in making everything else "just work" and >> be reliable enough to ship. > > I haven’t ramped up the marketing in a big way yet, but what I am > doing is quite effective (e.g. click through metrics are 5 to 10x the > norm); what’s been most astonishing is the word of mouth spread. > > Yes, lots of effort in having a reliable, supportable product. > > As you can see from the site, my messaging has been focused on regular > end users, using terminology they can hopefully grasp (I get accused > of both being too technical and not technical enough, so maybe I got > it right ;-) > > One area of messaging that I believe members of this list could > provide input on is around how to get people to understand that > ‘speed’ (line capacity) is not everything. I keep looking for ways to > address that and wrote a short post on it: > http://evenroute.com/the-last-50-feet/quick-vs-fast Well, there's Stuart's classic rant from two decades ago (which is on the technical side): http://www.stuartcheshire.org/rants/Latency.html On the less technical side, there's this video from the RITE project: https://www.youtube.com/watch?v=F1a-eMF9xdY And this one that nicely showcases latency, but then draws the wrong conclusion (that you need more bandwidth to fix it): https://www.youtube.com/watch?v=_fNp37zFn9Q -Toke ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] COTS router with OpenWrt
Hi Dave, a special thanks to you for all the cheerleading and pushing you do on this topic. > I hope that your marketing campaign is being successful on these > fronts. It has always been my goal to "enable better products", but > not have the headache of making them myself, where 99.99% of the > effort is (like in cerowrt), in making everything else "just work" and > be reliable enough to ship. I haven’t ramped up the marketing in a big way yet, but what I am doing is quite effective (e.g. click through metrics are 5 to 10x the norm); what’s been most astonishing is the word of mouth spread. Yes, lots of effort in having a reliable, supportable product. As you can see from the site, my messaging has been focused on regular end users, using terminology they can hopefully grasp (I get accused of both being too technical and not technical enough, so maybe I got it right ;-) One area of messaging that I believe members of this list could provide input on is around how to get people to understand that ‘speed’ (line capacity) is not everything. I keep looking for ways to address that and wrote a short post on it: http://evenroute.com/the-last-50-feet/quick-vs-fast I’ll post more thoughts on the other thread you started. - Jonathan > On Nov 28, 2016, at 10:57 AM, Dave Tahtwrote: > > On Mon, Nov 28, 2016 at 7:21 AM, Jonathan Foulkes > wrote: >> Thanks for the Introduction Rich, and thanks again to you and many others on >> this list for all your contributions over the years helping to combat bloat. >> >> This product was born of my own frustration with finding a way to help >> neighbors and family get a simple off-the-shelf solution that even >> non-technical users can deploy. > > I hope that your marketing campaign is being successful on these > fronts. It has always been my goal to "enable better products", but > not have the headache of making them myself, where 99.99% of the > effort is (like in cerowrt), in making everything else "just work" and > be reliable enough to ship. > >> >> I look forward to participating more actively on this list. > > One of my thoughts has been since it has become so difficult in the > USA for an open source organization to achieve 501c3 status (icei.org > is now 5 years into their attempt) was to go the 501c6 route, like the > linux foundation. We now have a reasonable set of companies doing the > right things for queueing, updates, and so on, that perhaps banding > together to promote "less lag, regular updates" would be a way to > support some of the other costs of this effort, such as effective > outreach. > >> >> Jonathan >> >>> On Nov 26, 2016, at 9:08 AM, Rich Brown wrote: >>> >>> I have been exchanging a few emails with Jonathan Foulkes from >>> evenroute.com. He tells me that his company is installing OpenWrt on a >>> commercial, off the shelf (COTS) TP-Link router and selling them on >>> commercially. His "secret sauce" is an auto-update facility and improved >>> setup software, which includes a rate-detection step that operates >>> continually to adjust the fq_codel parameters to the actual line rate. You >>> can take a look at IQrouter.com, or look them up on Amazon. >>> >>> This might be a solution to our current conundrum about not having an easy >>> solution that solves our family's networking problem. I'm going to get one >>> of these and try it out. >>> >>> He has been following our bufferbloat and make-fifi-fast work closely, as >>> well as the work on LEDE, which he'll consider once it hits a stable point. >>> I have invited him to join this list. >>> >>> Welcome, Jonathan. >>> >>> >> >> ___ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat > > > > -- > Dave Täht > Let's go make home routers and wifi faster! With better software! > http://blog.cerowrt.org ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Fixing bufferbloat in 2017
On Mon, Nov 28, 2016 at 8:58 AM, Stephen Hemmingerwrote: > My experience has been that the media and developer attention span is short > lived, and maybe that is part of the problem. Well, in portions of the market, the only way to get attention is to buy it, with press releases. I certainly plan a press release for whenever the wifi airtime fairness paper is published, and perhaps doing one sooner than that is warranted. I hope that wifi devices now being sold from some of the newer players all incorporate it and ship better products in 2017. >Gaming is a niche market, and therefore is easily ignored; plus the classic >gaming market is dying and I am not sure anyone is really investing in it. But a big one, and it doesn't matter if you use a dedicated device or not to game with. I think doing a "fixing your lag" talk at an E3 and trying to get more cloudy gaming companies (as well as VR ones) behind fixing the Internet would be a good thing to try. > The current hot topic use case seems to be machine learning and voice > interaction. I wonder if we could build a use case something related to that? > "Ok Google, my house is on fire!!" -- "Sorry can not call fire department, > network is congested". Well, I still like videoconferencing as a key thing we're enabling. There's been much progress there - I just learned that jitsy now has the "google congestion control" algorithm in it. The discussion was here: https://www.vuc.me/ And in other news, on needing regular, reliable software updates - this just in. 41 million routers have this port exposed. https://isc.sans.edu/forums/diary/Port+7547+SOAP+Remote+Code+Execution+Attack+Against+DSL+Modems/21759 thought this fall's DDOSes were bad? > > -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Fixing bufferbloat in 2017
My experience has been that the media and developer attention span is short lived, and maybe that is part of the problem. Gaming is a niche market, and therefore is easily ignored; plus the classic gaming market is dying and I am not sure anyone is really investing in it. The current hot topic use case seems to be machine learning and voice interaction. I wonder if we could build a use case something related to that? "Ok Google, my house is on fire!!" -- "Sorry can not call fire department, network is congested". ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] COTS router with OpenWrt
On Mon, Nov 28, 2016 at 7:21 AM, Jonathan Foulkeswrote: > Thanks for the Introduction Rich, and thanks again to you and many others on > this list for all your contributions over the years helping to combat bloat. > > This product was born of my own frustration with finding a way to help > neighbors and family get a simple off-the-shelf solution that even > non-technical users can deploy. I hope that your marketing campaign is being successful on these fronts. It has always been my goal to "enable better products", but not have the headache of making them myself, where 99.99% of the effort is (like in cerowrt), in making everything else "just work" and be reliable enough to ship. > > I look forward to participating more actively on this list. One of my thoughts has been since it has become so difficult in the USA for an open source organization to achieve 501c3 status (icei.org is now 5 years into their attempt) was to go the 501c6 route, like the linux foundation. We now have a reasonable set of companies doing the right things for queueing, updates, and so on, that perhaps banding together to promote "less lag, regular updates" would be a way to support some of the other costs of this effort, such as effective outreach. > > Jonathan > >> On Nov 26, 2016, at 9:08 AM, Rich Brown wrote: >> >> I have been exchanging a few emails with Jonathan Foulkes from >> evenroute.com. He tells me that his company is installing OpenWrt on a >> commercial, off the shelf (COTS) TP-Link router and selling them on >> commercially. His "secret sauce" is an auto-update facility and improved >> setup software, which includes a rate-detection step that operates >> continually to adjust the fq_codel parameters to the actual line rate. You >> can take a look at IQrouter.com, or look them up on Amazon. >> >> This might be a solution to our current conundrum about not having an easy >> solution that solves our family's networking problem. I'm going to get one >> of these and try it out. >> >> He has been following our bufferbloat and make-fifi-fast work closely, as >> well as the work on LEDE, which he'll consider once it hits a stable point. >> I have invited him to join this list. >> >> Welcome, Jonathan. >> >> > > ___ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Fixing bufferbloat in 2017
On Mon, Nov 28, 2016 at 7:23 AM, Wesley Eddywrote: > On 11/28/2016 10:12 AM, Dave Taht wrote: >> >> On Mon, Nov 28, 2016 at 4:48 AM, David Collier-Brown >> wrote: >>> >>> A short RFC with a clear summary would change the ground on which we >>> stand. >>> Include me in if you're planning one. >> >> Call me grumpy. Call me disaffected. But it's been 4 years into the >> IETF RFC process with codel and fq_codel with still no end in sight. >> > > > Hi Dave, while it's been undeniably slow, "no end in sight" is not really > accurate. Here is the correct status, since I am document shepherd for > both: > > - The fq-codel draft is completely and totally done in terms of IETF > process, and has been in the RFC Editor's queue simply awaiting the codel > draft to arrive. This is what the "MISSREF" state indicates in that IETF > datatracker tool. It completed the IETF last call and IESG balloting in > March/April earlier this year. > > - The codel document completed AQM working group last call, and I believe is > awaiting the authors to make changes requested by the Area Director in order > to go for IETF Last Call and IESG balloting. > > The end is most definitely within sight! Thank you for the update! I will, however, believe it when I see it (and heave a great sigh of relief). I see from looking over this preliminary draft, http://snapon.lab.bufferbloat.net/~d/draft-taht-home-gateway-best-practices-00.html that since I wrote it, we have made a serious dent in dealing with nat and in per host fq with the cake project, as well as dealing well with rate shaping (and diffserv classification to the best of our understandings) current man page for cake: http://static.lochnair.net/bufferbloat/tc-cake.8.html Some tech detail (does not include the new de-natting code or per host fq (triple-isolate)): https://www.bufferbloat.net/projects/codel/wiki/CakeTechnical/ There is *no way* I want to submit cake to the RFC process (the code is dual licensed), but an updated form of this attempt at a best practices document might be worthwhile, if not as a wg submission, then as an individual submission. > > > ___ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Fixing bufferbloat in 2017
On 11/28/2016 10:12 AM, Dave Taht wrote: On Mon, Nov 28, 2016 at 4:48 AM, David Collier-Brownwrote: A short RFC with a clear summary would change the ground on which we stand. Include me in if you're planning one. Call me grumpy. Call me disaffected. But it's been 4 years into the IETF RFC process with codel and fq_codel with still no end in sight. Hi Dave, while it's been undeniably slow, "no end in sight" is not really accurate. Here is the correct status, since I am document shepherd for both: - The fq-codel draft is completely and totally done in terms of IETF process, and has been in the RFC Editor's queue simply awaiting the codel draft to arrive. This is what the "MISSREF" state indicates in that IETF datatracker tool. It completed the IETF last call and IESG balloting in March/April earlier this year. - The codel document completed AQM working group last call, and I believe is awaiting the authors to make changes requested by the Area Director in order to go for IETF Last Call and IESG balloting. The end is most definitely within sight! ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Fixing bufferbloat in 2017
On Mon, Nov 28, 2016 at 7:14 AM, Pedro Tumusokwrote: > > > On Mon, Nov 28, 2016 at 1:48 PM, David Collier-Brown > wrote: >> >> A short RFC with a clear summary would change the ground on which we >> stand. >> Include me in if you're planning one. For the record, the rfc output of the aqm working group is here: https://tools.ietf.org/wg/aqm/ And I'd made an attempt at developing a short RFC http://snapon.lab.bufferbloat.net/~d/draft-taht-home-gateway-best-practices-00.html but encountered so much flack from the aqm-ers on the list, that I gave up, and decided to concentrate on getting the code out there on multiple platforms, to finding the problems in the algorithms in the real world, and creating de-facto standards. >> >> --dave >> > > There are some RFCs that vendors uses for throughput testing, RFC2544 I have > seen on a few Firewall vendors datasheets atleast, not seen any reference > RFC3511. > > Pedro > > >> >> >> On 28/11/16 01:00 AM, Jan Ceuleers wrote: >>> >>> On 28/11/16 03:16, Jim Gettys wrote: Ookla may have made themselves long term irrelevant by their recent behavior. When your customers start funding development of a replacement (as Comcast has), you know they aren't happy. So I don't sweat Ookla: helping out the Comcast test effort is probably the best way to get bufferbloat in front of everyone, and best yet, the code for the tests is out there. >>> >>> I do hope you're right Jim, but I still worry that Ookla is heavily >>> entrenched in carriers' test labs. This position has, I believe, come >>> about not because of Ookla's expertise in network testing but rather >>> because of market pull (i.e. speedtest.net's huge popularity with >>> end-users). >>> >>> As long as both of these positions remain (i.e. Ookla's mind share of >>> end-users and their resulting market share in the labs of large >>> purchasers of CPE) their lack of interest in bufferbloat is going to >>> keep this topic off the agenda in a large part of the industry. >>> >>> Unless Ookla can be coerced somehow. >>> >>> I have previously suggested standardising network throughput testing >>> methods and "grading" criteria. If there's an RFC on this subject >>> carriers are going to be interested in conformance to it and will >>> pressure their suppliers (of network testing gear, of CPE etc). >>> ___ >>> Bloat mailing list >>> Bloat@lists.bufferbloat.net >>> https://lists.bufferbloat.net/listinfo/bloat >> >> >> >> -- >> David Collier-Brown, | Always do right. This will gratify >> System Programmer and Author | some people and astonish the rest >> dav...@spamcop.net | -- Mark Twain >> >> >> ___ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat > > > > > -- > Best regards / Mvh > Jan Pedro Tumusok > > > ___ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Fixing bufferbloat in 2017
On Mon, Nov 28, 2016 at 1:48 PM, David Collier-Brownwrote: > A short RFC with a clear summary would change the ground on which we stand. > Include me in if you're planning one. > > --dave > > There are some RFCs that vendors uses for throughput testing, RFC2544 I have seen on a few Firewall vendors datasheets atleast, not seen any reference RFC3511. Pedro > > On 28/11/16 01:00 AM, Jan Ceuleers wrote: > >> On 28/11/16 03:16, Jim Gettys wrote: >> >>> Ookla may have made themselves long term irrelevant by their recent >>> behavior. When your customers start funding development of a >>> replacement (as Comcast has), you know they aren't happy. >>> >>> So I don't sweat Ookla: helping out the Comcast test effort is probably >>> the best way to get bufferbloat in front of everyone, and best yet, the >>> code for the tests is out there. >>> >> I do hope you're right Jim, but I still worry that Ookla is heavily >> entrenched in carriers' test labs. This position has, I believe, come >> about not because of Ookla's expertise in network testing but rather >> because of market pull (i.e. speedtest.net's huge popularity with >> end-users). >> >> As long as both of these positions remain (i.e. Ookla's mind share of >> end-users and their resulting market share in the labs of large >> purchasers of CPE) their lack of interest in bufferbloat is going to >> keep this topic off the agenda in a large part of the industry. >> >> Unless Ookla can be coerced somehow. >> >> I have previously suggested standardising network throughput testing >> methods and "grading" criteria. If there's an RFC on this subject >> carriers are going to be interested in conformance to it and will >> pressure their suppliers (of network testing gear, of CPE etc). >> ___ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat >> > > > -- > David Collier-Brown, | Always do right. This will gratify > System Programmer and Author | some people and astonish the rest > dav...@spamcop.net | -- Mark Twain > > > ___ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat > -- Best regards / Mvh Jan Pedro Tumusok ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Fixing bufferbloat in 2017
On Mon, Nov 28, 2016 at 4:48 AM, David Collier-Brownwrote: > A short RFC with a clear summary would change the ground on which we stand. > Include me in if you're planning one. Call me grumpy. Call me disaffected. But it's been 4 years into the IETF RFC process with codel and fq_codel with still no end in sight. I presently have no hope that a "short RFC" can enter and exit the IETF in a reasonable amount of time, without being watered down into unreadability. > > --dave > > > On 28/11/16 01:00 AM, Jan Ceuleers wrote: >> >> On 28/11/16 03:16, Jim Gettys wrote: >>> >>> Ookla may have made themselves long term irrelevant by their recent >>> behavior. When your customers start funding development of a >>> replacement (as Comcast has), you know they aren't happy. >>> >>> So I don't sweat Ookla: helping out the Comcast test effort is probably >>> the best way to get bufferbloat in front of everyone, and best yet, the >>> code for the tests is out there. >> >> I do hope you're right Jim, but I still worry that Ookla is heavily >> entrenched in carriers' test labs. This position has, I believe, come >> about not because of Ookla's expertise in network testing but rather >> because of market pull (i.e. speedtest.net's huge popularity with >> end-users). >> >> As long as both of these positions remain (i.e. Ookla's mind share of >> end-users and their resulting market share in the labs of large >> purchasers of CPE) their lack of interest in bufferbloat is going to >> keep this topic off the agenda in a large part of the industry. >> >> Unless Ookla can be coerced somehow. >> >> I have previously suggested standardising network throughput testing >> methods and "grading" criteria. If there's an RFC on this subject >> carriers are going to be interested in conformance to it and will >> pressure their suppliers (of network testing gear, of CPE etc). >> ___ >> Bloat mailing list >> Bloat@lists.bufferbloat.net >> https://lists.bufferbloat.net/listinfo/bloat > > > > -- > David Collier-Brown, | Always do right. This will gratify > System Programmer and Author | some people and astonish the rest > dav...@spamcop.net | -- Mark Twain > > > ___ > Bloat mailing list > Bloat@lists.bufferbloat.net > https://lists.bufferbloat.net/listinfo/bloat -- Dave Täht Let's go make home routers and wifi faster! With better software! http://blog.cerowrt.org ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Fixing bufferbloat in 2017
The biggest problem I see with speedtest-like network testing... is the tests don't last long enough. I've begun making that joke at every presentation - pointing at the bloat spike at T+18 or T+22 seconds - how many of you only use your networks for 30 seconds a day? ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat
Re: [Bloat] Fixing bufferbloat in 2017
A short RFC with a clear summary would change the ground on which we stand. Include me in if you're planning one. --dave On 28/11/16 01:00 AM, Jan Ceuleers wrote: On 28/11/16 03:16, Jim Gettys wrote: Ookla may have made themselves long term irrelevant by their recent behavior. When your customers start funding development of a replacement (as Comcast has), you know they aren't happy. So I don't sweat Ookla: helping out the Comcast test effort is probably the best way to get bufferbloat in front of everyone, and best yet, the code for the tests is out there. I do hope you're right Jim, but I still worry that Ookla is heavily entrenched in carriers' test labs. This position has, I believe, come about not because of Ookla's expertise in network testing but rather because of market pull (i.e. speedtest.net's huge popularity with end-users). As long as both of these positions remain (i.e. Ookla's mind share of end-users and their resulting market share in the labs of large purchasers of CPE) their lack of interest in bufferbloat is going to keep this topic off the agenda in a large part of the industry. Unless Ookla can be coerced somehow. I have previously suggested standardising network throughput testing methods and "grading" criteria. If there's an RFC on this subject carriers are going to be interested in conformance to it and will pressure their suppliers (of network testing gear, of CPE etc). ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat -- David Collier-Brown, | Always do right. This will gratify System Programmer and Author | some people and astonish the rest dav...@spamcop.net | -- Mark Twain ___ Bloat mailing list Bloat@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/bloat