[Bloat] came across an unexpected side-effect of bufferbloat

[Bloat] came across an unexpected side-effect of bufferbloat

[jb]

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

Dave's email made me remember something I came across today.

So someone was looking for ways to take advantage of Amazon Prime unlimited
photo uploading. They had 4.5TB of data to upload.

While researching a little I came across a message on the Amazon support
forums that said after 3 hours of uploading to Amazon, their cable modem
would crash and reboot. The reason was that the SNMP the cable modem needed
to stay healthy was timing out (due to the excessive latency induced by the
continuous uploading). The author didn't know it was bufferbloat, of course.

I thought that was an interesting little result of never testing "full
speed" for long periods of time.

Imagine buying a car that had never been tested at top speed for an hour at
a proving ground.

cheers
-Justin

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

Re: [Bloat] came across an unexpected side-effect of bufferbloat

[Steinar H. Gunderson]

On Mon, Aug 03, 2015 at 11:53:40PM +1000, jb wrote:
> While researching a little I came across a message on the Amazon support
> forums that said after 3 hours of uploading to Amazon, their cable modem
> would crash and reboot. The reason was that the SNMP the cable modem needed
> to stay healthy was timing out (due to the excessive latency induced by the
> continuous uploading). The author didn't know it was bufferbloat, of course.

FWIW, you don't need bufferbloat for this to fail. A classic thing with
switches (typically underbuffered rather than overbuffered!) is that when you
run the links full, the OSPF packets get dropped and eventually your link
flaps because the other side thinks you're down.

This is one of the reasons why most L3 switches (well, anything that's
advanced enough to do OSPF or the likes in the first place :-) ) have QoS at
all: You need to protect your administrative traffic.

/* Steinar */
-- 
Homepage: http://www.sesse.net/

Re: [Bloat] came across an unexpected side-effect of bufferbloat

[Bill Ver Steeg (versteb)]

It is even worse than that - On some really crappy low end devices, applications do not get a taste of the CPU if there is a packet to be sent. If there is always a packet to be sent, the SNMP daemon and/or some DOCSIS/DSL/FTTx tasks (and other application level tasks that need to interact with the control plane) don't run. Eventually something weird happens, like a memory leak or a dead-man timer and  the box reboots. Clearly, this is sub-optimal. 

Fortunately, Darwinian pressures have made this type of device less prevalent in the marketplace. You can still run into some really poor CPE in the wild, though.


Bill VerSteeg

-----Original Message-----
From: bloat-bounces@lists.bufferbloat.net [mailto:bloat-bounces@lists.bufferbloat.net] On Behalf Of Steinar H. Gunderson
Sent: Monday, August 03, 2015 10:01 AM
To: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] came across an unexpected side-effect of bufferbloat

On Mon, Aug 03, 2015 at 11:53:40PM +1000, jb wrote:
> While researching a little I came across a message on the Amazon 
> support forums that said after 3 hours of uploading to Amazon, their 
> cable modem would crash and reboot. The reason was that the SNMP the 
> cable modem needed to stay healthy was timing out (due to the 
> excessive latency induced by the continuous uploading). The author didn't know it was bufferbloat, of course.

FWIW, you don't need bufferbloat for this to fail. A classic thing with switches (typically underbuffered rather than overbuffered!) is that when you run the links full, the OSPF packets get dropped and eventually your link flaps because the other side thinks you're down.

This is one of the reasons why most L3 switches (well, anything that's advanced enough to do OSPF or the likes in the first place :-) ) have QoS at
all: You need to protect your administrative traffic.

/* Steinar */
--
Homepage: http://www.sesse.net/
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat

Re: [Bloat] came across an unexpected side-effect of bufferbloat

[Dave Taht]

This is precisely the sort of failures I (perversely) hope to induce
at battlemesh, using flent to drive the network to saturation.

On Mon, Aug 3, 2015 at 7:00 AM, Steinar H. Gunderson
<sgunderson@bigfoot.com> wrote:
> On Mon, Aug 03, 2015 at 11:53:40PM +1000, jb wrote:
>> While researching a little I came across a message on the Amazon support
>> forums that said after 3 hours of uploading to Amazon, their cable modem
>> would crash and reboot. The reason was that the SNMP the cable modem needed
>> to stay healthy was timing out (due to the excessive latency induced by the
>> continuous uploading). The author didn't know it was bufferbloat, of course.
>
> FWIW, you don't need bufferbloat for this to fail. A classic thing with
> switches (typically underbuffered rather than overbuffered!) is that when you
> run the links full, the OSPF packets get dropped and eventually your link
> flaps because the other side thinks you're down.
>
> This is one of the reasons why most L3 switches (well, anything that's
> advanced enough to do OSPF or the likes in the first place :-) ) have QoS at
> all: You need to protect your administrative traffic.
>
> /* Steinar */
> --
> Homepage: http://www.sesse.net/
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat



-- 
Dave Täht
worldwide bufferbloat report:
http://www.dslreports.com/speedtest/results/bufferbloat
And:
What will it take to vastly improve wifi for everyone?
https://plus.google.com/u/0/explore/makewififast