Re: [Bloat] How to "sell" improvement

[David Collier-Brown]

On 28/11/16 02:26 PM, Jonathan Morton wrote:

On 28 Nov, 2016, at 20:37, David Collier-Brown  wrote:

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

[David Lang]

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

[Jonathan Morton]

> On 28 Nov, 2016, at 20:37, David Collier-Brown  wrote:
> 
> 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

[David Collier-Brown]

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-Brown  wrote:

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

[Jonathan Morton]

> On 28 Nov, 2016, at 19:07, Dave Taht  wrote:
> 
> (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

[Simon Barber]

Web page load time.

Simon

> On Nov 28, 2016, at 10:37 AM, David Collier-Brown  wrote:
> 
> 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

[David Collier-Brown]

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

Re: [Bloat] How to "sell" improvement

[Kathleen Nichols]

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

[Kathleen Nichols]

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)

[David Collier-Brown]

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

Re: [Bloat] COTS router with OpenWrt

[Toke Høiland-Jørgensen]

Jonathan Foulkes  writes:

> 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

[Jonathan Foulkes]

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 Taht  wrote:
> 
> 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

[Dave Taht]

On Mon, Nov 28, 2016 at 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.

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

[Stephen Hemminger]

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

[Dave Taht]

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

[Dave Taht]

On Mon, Nov 28, 2016 at 7:23 AM, Wesley Eddy  wrote:
> 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

[Wesley Eddy]

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!


___
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] Fixing bufferbloat in 2017

[Dave Taht]

On Mon, Nov 28, 2016 at 7:14 AM, Pedro Tumusok  wrote:
>
>
> 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

[Pedro Tumusok]

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.
>
> --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

[Dave Taht]

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.

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

[Dave Taht]

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

[David Collier-Brown]

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