Re: [Bloat] RED against bufferbloat

[Jonathan Morton <chromatix99@gmail.com>]

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

To add my tuppence to this discussion:

I don't believe real world topologies and workloads are incompatible with
academic experimentation. All you have to do is replicate the same workload
and other conditions across each of the qdiscs you're testing, ie to change
only the qdisc between test runs. That's the basis of the scientific method.

Using a simplified topology and workload may well give you clearer and more
understandable results from which you can more easily draw a conclusion for
your paper. But that conclusion becomes correspondingly less relevant to
practical applications and bleeding edge research, as others have explained.

In the real world, I have a 3G connection shaped to half a megabit at the
provider, occasionally limited to EDGE speeds at the tower depending on
propagation conditions, typical idle latency 100ms, potential loaded
latency the best part of a MINUTE. I'm not even sure what the upload
bandwidth rate or topology is supposed to be. Packet loss is usually
acceptably low, yet the horrible loaded latency means that I can't do more
than one thing at a time on my phone; it even logs me out of Steam chat if
I load a big web page, and it also takes time to drain the traffic out of
the queue after I cancel something to do something else, or to do it a
different way.

Just now I wanted to watch an NTSB media briefing; Twitter tried to load a
preview of the video just before I clicked the link to launch the proper
YouTube app (which can do fullscreen); with the buffer thus filled, YouTube
decided the network was broken and refused to load the video. In fact it
left the navigation settings on the previous video I watched yesterday, so
that when I hit retry, it loaded that video rather than the one I'd just
clicked the link for. That's a real world workload, and a real world
failure of epic proportions, and it didn't even need bidirectional traffic
to trigger.

- Jonathan Morton

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