From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi0-x231.google.com (mail-oi0-x231.google.com [IPv6:2607:f8b0:4003:c06::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by lists.bufferbloat.net (Postfix) with ESMTPS id 1A95D3B260 for ; Fri, 26 Aug 2016 20:20:05 -0400 (EDT) Received: by mail-oi0-x231.google.com with SMTP id 188so41501253oif.2 for ; Fri, 26 Aug 2016 17:20:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=M90Jp/pjl94ogMNIvN/kgTSNiU2TTOufQ0YP/ZssUEE=; b=HrPfFBsv5pgreAd2cvFAh9ZKByitUCJbTpfBRTPaAwBhIkZHy8blYCdAHyrX+KcvHo CeG5PoSb0oA6nUw8cxrMzdUXs9Fnb5Sgy72Pa5ADDwi9sfZxONhdkrse829IUvyUeWLt mTz5sPqFI33n6JBlKTpGtr386Vc/gqzq18uVZylKjAS3Hxwq6VFscL/n6MU/P06uhRgU 3YwW6J/nTOYWbCEPbsW0iHPoS3NNOIL2TIXVsxYSUZbQaR799kfFYEmqeqQv3ov5dyRT Fsagbm5u3219Xz5fpafzPgGxF2OasTOM8UyqbsG1ry0vl0p6DBYHpQ+AOl+3akCGbMfu nAwQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=M90Jp/pjl94ogMNIvN/kgTSNiU2TTOufQ0YP/ZssUEE=; b=XmFoaxlgdkrma/tGJqvbgdCTL/YdLsT2ncTUnoldMuWcKCISZxHKlotujGwe09Sjj7 SNgwCLLz8UKwTFhjMbs7cEW886mhaWejExTJuU2mk8XK1hT9ISzfkIkj+waJLhV+Dg9W exEGKPLGcGCJPPcazYLHSR4x65MePBKq4H1MKMQyAYEATpn3A79Tij3hHWYDljlABXoW VnMn8XDo0hZ7J7i3hbHuWmEkpKlpu1Sfq48+cdLL0vuph1uqCgwizDRE2iF//sw24jub uyJvyEkWrjFCEMrj6UrGuLA51Gwyhx1PrrBEsP+JP2kva53lGGNq5HfY5+xGZ4VvHleu XSOA== X-Gm-Message-State: AE9vXwMxNCeGssqOGdOvMRc4i0LTmIA1ZE/jN8L60kVacZ0zbN+36lJ9P6cFrVDGcTxFwhEEYiRRAp+wz8YTFg== X-Received: by 10.157.33.15 with SMTP id i15mr4940187otb.75.1472257204387; Fri, 26 Aug 2016 17:20:04 -0700 (PDT) MIME-Version: 1.0 Received: by 10.157.46.58 with HTTP; Fri, 26 Aug 2016 17:20:03 -0700 (PDT) In-Reply-To: <90667e99-1334-af36-5879-3b4ed362ed68@pollere.com> References: <0B9BB2F0-611E-4388-8784-0AC71556AB4B@cable.comcast.com> <20160824090847.4e77ce8f@xeon-e3> <1C99BD90-7688-4168-814D-57DA12F0F08C@cable.comcast.com> <90667e99-1334-af36-5879-3b4ed362ed68@pollere.com> From: Benjamin Cronce Date: Fri, 26 Aug 2016 19:20:03 -0500 Message-ID: To: Kathleen Nichols Cc: bloat Content-Type: multipart/alternative; boundary=001a11418b0aaf85f0053b02975f Subject: Re: [Bloat] Open Source Speed Test (was fast.com - Netflix's speed monitoring) X-BeenThere: bloat@lists.bufferbloat.net X-Mailman-Version: 2.1.20 Precedence: list List-Id: General list for discussing Bufferbloat List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Aug 2016 00:20:05 -0000 --001a11418b0aaf85f0053b02975f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, Aug 26, 2016 at 6:13 PM, Kathleen Nichols 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=E2=80=99re hopin= g folks > might help prior to the hackathon or at the hackathon=E2=80=A6 =E2=98=BA > > > > Jason > > > > > > _______________________________________________ > > 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 > --001a11418b0aaf85f0053b02975f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Fri, Aug 26, 2016 at 6:13 PM, Kathleen Nichols <= ;nichols@pollere.c= om> 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 c= onfigured. I only know two things. They are using Calix for the last mile a= nd don't do any rate limiting in the last mile. They use a Cisco core r= outer where they do all of their rate limiting. Prior to their Cisco core r= outer, 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 sa= w-tooth and more like a high frequency sine-wave

H= ere are two speedtests with no traffic shaping on my end,
<= div>
This is what it looks like when I enabled Codel on my fi= rewall
=C2=A0
<= div>This is what it looks like when I'm seeding about 20Mb/s and my wif= e is watching Netflix while I do a speedtest with Codel

Speaking of large buff= ers. I have been able to get my ISP's AQM to have massive bursts of lat= ency, but it required my to have my connection DDOSd. Since the rate limiti= ng 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 a= ble to get brief pings into the 4k ms range before the AQM just started dro= pping nearly all packets.

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

Leve= l 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 ups= tream 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 us= es 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 hard= ware, but I would like to know what hardware and what implementation and wh= y 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 existe= nce of
large queues? I think
the latter.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 Kathie

On 8/24/16 10:28 AM, Livingood, Jason wrote:
>> Why doesn't the test measure bufferbloat like FLENT or dslrepo= rts test?
>
> We have not gotten to it yet; it is in our backlog. We=E2=80=99re hopi= ng folks might help prior to the hackathon or at the hackathon=E2=80=A6=C2= =A0 =E2=98=BA
>
> Jason
>
>
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat= .net
> https://lists.bufferbloat.net/listinfo/bloat
>

_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net<= /a>
https://lists.bufferbloat.net/listinfo/bloat

--001a11418b0aaf85f0053b02975f--