[Bloat] Bufferbloat: GoGo blocking YouTube

[Jonathan Morton]

> On 6 Jan, 2015, at 22:45, Hal Murray <hmurray at megapathdsl.net> wrote:
> 
> GoGo provides internet access on airplanes.  They want to block YouTube 
> (and similar) to avoid overloading their thin pipes.  They are doing that by 
> intercepting https connections and presenting bogus certificates.

…WTF?

Look - if you *want* to block YouTube, then you block YouTube.  People might get a little annoyed about that, but it’ll probably be limited to minor grumbling.  You *don’t* fiddle with traffic to it.  There is something *seriously* wrong if that’s the first or best solution that came to mind.

I agree with the conclusion of the article, though.  There’s a straightforward, network-neutral, technological solution which actually solves the original problem.  Shame almost nobody’s heard of it.

Incidentally, I finally got my test setup running properly.  It now has cake running on each of two Fast Ethernet interfaces in the Pentium-MMX, which are bridged.  It is able to comfortably pass 50Mbps through that before it runs out of CPU grunt - but that’s 50Mbps total.  It doesn’t matter whether it’s all one way, all the other way, or half each.  I then set it up to simulate a 24/3 Mbps ADSL, and it did that with about 50% CPU time in soft-interrupt mode.

I haven’t tried cake2 yet.

The limiting factor may well be context switching, or at least interrupt handling overhead.  That’s quite expensive on x86 and on a full OS like Linux; far more so than on, say, an ARM running in a dedicated embedded configuration.  (ARM has banks of registers which are switched in, replacing the originals, for interrupt handlers, so it doesn’t have to hurriedly save all those registers before it can do anything useful.)  Bridging, and running *both* the traffic endpoints on other machines, rather than keeping one endpoint on the Pentium-MMX, improves the throughput markedly.

 - Jonathan Morton