[Bloat] Open Source Speed Test (was fast.com - Netflix's speed monitoring)

[Benjamin Cronce]

On Fri, Aug 26, 2016 at 6:13 PM, Kathleen Nichols <nichols at pollere.com>
wrote:

>
> I think it might be useful to say these tests measure the maximum
> *potential* for
> bufferbloat. That is, they plumb the depths of the buffers in the path.
> I tried running
> dslreports while I was running a video and though dslreports ramps
> delays up to 700ms,
> before and after that peak delay is more like 45ms. I don't think large
> buffers are going
>
I would like to know how my ISP is configured. I only know two things. They
are using Calix for the last mile and don't do any rate limiting in the
last mile. They use a Cisco core router where they do all of their rate
limiting. Prior to their Cisco core router, they use the rate limiting on
the ONT. It was strict and created the normal TCP saw-tooth pattern. After
the change over, it was no longer a saw-tooth and more like a high
frequency sine-wave

Here are two speedtests with no traffic shaping on my end,
https://www.dslreports.com/speedtest/4703254
https://www.dslreports.com/speedtest/4703265

This is what it looks like when I enabled Codel on my firewall
https://www.dslreports.com/speedtest/4698506

This is what it looks like when I'm seeding about 20Mb/s and my wife is
watching Netflix while I do a speedtest with Codel
https://www.dslreports.com/speedtest/4702550

Speaking of large buffers. I have been able to get my ISP's AQM to have
massive bursts of latency, but it required my to have my connection DDOSd.
Since the rate limiting is done in the core router for all customers, it
must have a huge buffer. If I have a service DDOS me, used to be 100Mb
connection, with 200Mb/s of UDP, going from perfectly idle to fully
saturated with no ramp-up, I was able to get brief pings into the 4k ms
range before the AQM just started dropping nearly all packets.

What was interesting is after the AQM kicked in, even though I was getting
something like 80% packetloss, my ping stayed around 30ms above idle.

Level 3 comm also seems to have some sort of AQM or they do with my ISP. At
one point my ISP was getting about 15% loss between them and their Level 3
upstream hop. I called up and I was told they were getting DDOSd. Even
during this attack, the ping never spiked more than 20ms to Level 3. Or
Level 3 uses really really small buffers. During this time the ping to my
ISP was its normal healthy stable low value, so I know all of the jitter
was the trunk.

There is hope. It's making its way into hardware, but I would like to know
what hardware and what implementation and why isn't this being more used?

to go away, what matters is whether they are getting filled up.
>
> So, is "bufferbloat" the existence of large buffers or the existence of
> large queues? I think
> the latter.
>
>         Kathie
>
> On 8/24/16 10:28 AM, Livingood, Jason wrote:
> >> Why doesn't the test measure bufferbloat like FLENT or dslreports test?
> >
> > We have not gotten to it yet; it is in our backlog. We’re hoping folks
> might help prior to the hackathon or at the hackathon…  ☺
> >
> > Jason
> >
> >
> > _______________________________________________
> > Bloat mailing list
> > Bloat at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/bloat
> >
>
> _______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/bloat/attachments/20160826/8d361d2e/attachment-0002.html>