[Bloat] General Bufferbloat Testing Document.

[Bloat] General Bufferbloat Testing Document.

[Jim Gettys]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

Even before I knew about the wonderful DSLreports bufferbloat test, I had
started working on a document to help people like that (e.g. Ookla)
understand how to do bufferbloat testing.  The document also grew a bit
beyond that topic, by the time it was done....

The document is at:

https://docs.google.com/document/d/1z5NN4WRKQKK-RtxtKR__XIwkybvsKEmunek2Ezdw_90/edit?usp=sharing

Comments welcome.

It's intended long term home is the bufferbloat.net wiki, but I've found
Google doc's commenting feature really useful.
                           - Jim

[-- Attachment #2: Type: text/html, Size: 1200 bytes --]

Re: [Bloat] General Bufferbloat Testing Document.

[Stephen Hemminger]

On Fri, 15 May 2015 12:16:56 -0400
Jim Gettys <jg@freedesktop.org> wrote:

> Even before I knew about the wonderful DSLreports bufferbloat test, I had
> started working on a document to help people like that (e.g. Ookla)
> understand how to do bufferbloat testing.  The document also grew a bit
> beyond that topic, by the time it was done....
> 
> The document is at:
> 
> https://docs.google.com/document/d/1z5NN4WRKQKK-RtxtKR__XIwkybvsKEmunek2Ezdw_90/edit?usp=sharing
> 
> Comments welcome.
> 
> It's intended long term home is the bufferbloat.net wiki, but I've found
> Google doc's commenting feature really useful.
>                            - Jim

Great to see, I think it does a good job of being detailed without overwhelmingly
research oriented.

What makes you believe SPDY and QUIC will be better than TCP? I know they do
pacing but if they get the rate estimation wrong or get hit by transient congestion
it could have same failing that doomed TCP Vegas.

Re: [Bloat] General Bufferbloat Testing Document.

[Alan Jenkins]

On 16/05/15 01:17, Stephen Hemminger wrote:
> On Fri, 15 May 2015 12:16:56 -0400
> Jim Gettys <jg@freedesktop.org> wrote:
>
>> Even before I knew about the wonderful DSLreports bufferbloat test, I had
>> started working on a document to help people like that (e.g. Ookla)
>> understand how to do bufferbloat testing.  The document also grew a bit
>> beyond that topic, by the time it was done....
>>
>> The document is at:
>>
>> https://docs.google.com/document/d/1z5NN4WRKQKK-RtxtKR__XIwkybvsKEmunek2Ezdw_90/edit?usp=sharing
>>
>> Comments welcome.
>>
>> It's intended long term home is the bufferbloat.net wiki, but I've found
>> Google doc's commenting feature really useful.
>>                             - Jim
>
> Great to see, I think it does a good job of being detailed without overwhelmingly
> research oriented.
>
> What makes you believe SPDY and QUIC will be better than TCP? I know they do
> pacing but if they get the rate estimation wrong or get hit by transient congestion
> it could have same failing that doomed TCP Vegas.

HTTP/2 has working multiplexing.  This means you can reduce several 
simultaneous 'slow start' bursts to one.  Yay!

c.f. "These transients are caused by normal users in everyday use cases 
such as routine web surfing, due to embedded images inducing large 
numbers of TCP connections, and TCP’s initial window and TCP “slow 
start” (currently unpaced) landing in a single FIFO queue"

There's some hope sites will stop "sharding".  I.e. stop hosting 
resources on multiple domains to game how many connections the browser 
opens.  I guess it would let them avoid a round-trip from opening extra 
secondary connections.

Alan

Re: [Bloat] General Bufferbloat Testing Document.

[Rich Brown]

[-- Attachment #1: Type: text/plain, Size: 2100 bytes --]

Hi Jim,

I'm glad you've got this letter going. I have started to write (mentally) this note several times, but two things always checked my momentum:

- Last summer, I sent notes asking the big speed test sites simply to add a latency test. (speedtest.net, testmy.net, speedof.me). All three responded that (basically) they would ask their developers about it, and you can see the (non) results. 

- I'm afraid that it's not in their self-interest to add a latency test. Especially Ookla - I see their test package bundled as part of the offering for lots of ISPs. Ookla are hardly going to "enhance" their speed test in such a way that customer's customers can plainly see, "Congratulations on starting your service with us. You can see your speeds are pretty good, but you get an F- for bufferbloat."

The latter point is the reason that I'm so glad that Justin has added the latency test. DSLReports.com doesn't have any sacred cows to protect, so they're free to call it as it is. And I also love that they do it with a letter grade: "Hey, dude. Your connection is bloated, and you get a D".

There is still a long row to hoe, but as more and more people get de-bloated, the test will help spread around the knowledge that "it doesn't have to be that way". 

Rich


On May 15, 2015, at 12:16 PM, Jim Gettys <jg@freedesktop.org> wrote:

> Even before I knew about the wonderful DSLreports bufferbloat test, I had started working on a document to help people like that (e.g. Ookla) understand how to do bufferbloat testing.  The document also grew a bit beyond that topic, by the time it was done....
> 
> The document is at:
> 
> https://docs.google.com/document/d/1z5NN4WRKQKK-RtxtKR__XIwkybvsKEmunek2Ezdw_90/edit?usp=sharing
> 
> Comments welcome. 
> 
> It's intended long term home is the bufferbloat.net wiki, but I've found Google doc's commenting feature really useful.
>                            - Jim
> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat


[-- Attachment #2: Type: text/html, Size: 3504 bytes --]

Re: [Bloat] General Bufferbloat Testing Document.

[Jim Gettys]

[-- Attachment #1: Type: text/plain, Size: 3211 bytes --]

On Sat, May 16, 2015 at 7:43 AM, Rich Brown <richb.hanover@gmail.com> wrote:

> Hi Jim,
>
> I'm glad you've got this letter going. I have started to write (mentally)
> this note several times, but two things always checked my momentum:
>
> - Last summer, I sent notes asking the big speed test sites simply to add
> a latency test. (speedtest.net, testmy.net, speedof.me). All three
> responded that (basically) they would ask their developers about it, and
> you can see the (non) results.
>
> - I'm afraid that it's not in their self-interest to add a latency test.
> Especially Ookla - I see their test package bundled as part of the offering
> for lots of ISPs. Ookla are hardly going to "enhance" their speed test in
> such a way that customer's customers can plainly see, "Congratulations on
> starting your service with us. You can see your speeds are pretty good, but
> you get an F- for bufferbloat."
>

​Actually, I had a conversation a couple months ago with Doug Suttles at
Ookla.  He said they were interested/willing to add a bufferbloat test.

That's what spurred writing the document: to make their job easier; I
promised Doug on that phone call to write such a document.

Now we'll see if he follows through.

Note that some ISP's are actively interested in getting bufferbloat fixed
(e.g. Comcast, just look at Jason Livingood's recent tweets).  Bufferbloat
is between ISP's and the ability to provide better low latency services,
and some ISP's are wise enough to understand that.

So I don't think it's quite the situation that it appears on the surface.

>
> The latter point is the reason that I'm so glad that Justin has added the
> latency test. DSLReports.com doesn't have any sacred cows to protect, so
> they're free to call it as it is. And I also love that they do it with a
> letter grade: "Hey, dude. Your connection is bloated, and you get a D".
>
>
​I'm very happy to see DSLreport's test indeed.  I hope it encourages the
other testing services to follow through.

​If you have contacts at those services, please send them a link to the
document.​

​


> There is still a long row to hoe, but as more and more people get
> de-bloated, the test will help spread around the knowledge that "it doesn't
> have to be that way".
> ​​
>

​Yup.

Jim
​


>
> Rich
>
>
> On May 15, 2015, at 12:16 PM, Jim Gettys <jg@freedesktop.org> wrote:
>
> Even before I knew about the wonderful DSLreports bufferbloat test, I had
> started working on a document to help people like that (e.g. Ookla)
> understand how to do bufferbloat testing.  The document also grew a bit
> beyond that topic, by the time it was done....
>
> The document is at:
>
>
> https://docs.google.com/document/d/1z5NN4WRKQKK-RtxtKR__XIwkybvsKEmunek2Ezdw_90/edit?usp=sharing
>
> Comments welcome.
>
> It's intended long term home is the bufferbloat.net wiki, but I've found
> Google doc's commenting feature really useful.
>                            - Jim
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
>
>

[-- Attachment #2: Type: text/html, Size: 6805 bytes --]

Re: [Bloat] General Bufferbloat Testing Document.

[Rich Brown]

[-- Attachment #1: Type: text/plain, Size: 3315 bytes --]

Jim,

This is great news. 

> I'm glad you've got this letter going. I have started to write (mentally) this note several times, but two things always checked my momentum:
> 
> - Last summer, I sent notes asking the big speed test sites simply to add a latency test. (speedtest.net, testmy.net, speedof.me). All three responded that (basically) they would ask their developers about it, and you can see the (non) results. 
> 
> - I'm afraid that it's not in their self-interest to add a latency test. Especially Ookla - I see their test package bundled as part of the offering for lots of ISPs. Ookla are hardly going to "enhance" their speed test in such a way that customer's customers can plainly see, "Congratulations on starting your service with us. You can see your speeds are pretty good, but you get an F- for bufferbloat."
> 
> ​Actually, I had a conversation a couple months ago with Doug Suttles at Ookla.  He said they were interested/willing to add a bufferbloat test.

Hallelujah!

> That's what spurred writing the document: to make their job easier; I promised Doug on that phone call to write such a document.
> 
> Now we'll see if he follows through.
> 
> Note that some ISP's are actively interested in getting bufferbloat fixed (e.g. Comcast, just look at Jason Livingood's recent tweets).  Bufferbloat is between ISP's and the ability to provide better low latency services, and some ISP's are wise enough to understand that.

Comcast has been thinking about this a long time, and now has the science and technology in hand (DOCSIS 3.1/PIE), so I'm hoping they roll it out soon.

> So I don't think it's quite the situation that it appears on the surface.
> 
> The latter point is the reason that I'm so glad that Justin has added the latency test. DSLReports.com doesn't have any sacred cows to protect, so they're free to call it as it is. And I also love that they do it with a letter grade: "Hey, dude. Your connection is bloated, and you get a D".
> 
> 
> ​I'm very happy to see DSLreport's test indeed.  I hope it encourages the other testing services to follow through.
> 
> ​If you have contacts at those services, please send them a link to the document.​
> 
> ​ 
> There is still a long row to hoe, but as more and more people get de-bloated, the test will help spread around the knowledge that "it doesn't have to be that way". ​​
> 
> ​Yup.
> 
> Jim

Best,

Rich
> 
> Rich
> 
> 
> On May 15, 2015, at 12:16 PM, Jim Gettys <jg@freedesktop.org> wrote:
> 
>> Even before I knew about the wonderful DSLreports bufferbloat test, I had started working on a document to help people like that (e.g. Ookla) understand how to do bufferbloat testing.  The document also grew a bit beyond that topic, by the time it was done....
>> 
>> The document is at:
>> 
>> https://docs.google.com/document/d/1z5NN4WRKQKK-RtxtKR__XIwkybvsKEmunek2Ezdw_90/edit?usp=sharing
>> 
>> Comments welcome. 
>> 
>> It's intended long term home is the bufferbloat.net wiki, but I've found Google doc's commenting feature really useful.
>>                            - Jim
>> 
>> _______________________________________________
>> Bloat mailing list
>> Bloat@lists.bufferbloat.net
>> https://lists.bufferbloat.net/listinfo/bloat
> 
> 


[-- Attachment #2: Type: text/html, Size: 7261 bytes --]