One note: on my flight to Hawaii for the IETF, I tried running
netperf-wrapper to see just how bloated the airplane system was (I presume
it was GoGo, but don't know for sure: I was on United).

On my second attempt to run the test, the on board system crashed
entirely.  I did not try again.
                                  - Jim


On Tue, Jan 6, 2015 at 2:37 PM, Dave Taht <dave.taht@gmail.com> wrote:

> On Tue, Jan 6, 2015 at 9:26 AM,  <dpreed@reed.com> wrote:
> > GoGo does not need to run “Man in the Middle Attacks” on YouTube
>
> re: http://www.reed.com/blog-dpr/?p=174
>
> I amplified via g+ and mentioned to slashdot.
> (
> http://slashdot.org/submission/4107907/gogo-airline-network-blocks-youtube-when-they-could-just-fix-their-bufferbloat
> )  I don't use reddit, but if someone here wants to hit this topic
> there, perhaps it will help.
>
> I am very perturbed by the https interception stuff and agree that
> they should fix their bufferbloat instead! So should amtrak and other
> services trying to provide general useful email and web services when
> they too have limited bandwidth... in an age where people want dancing
> cat videos on the move and are completely ignorant of the hit on the
> network that induces.
>
> I have quite a few benchmarks of Gogo in flight. They all suck. I
> think the best deployable solution would require reworking their
> satellite uplink management to be available bandwidth aware...
> although I think they could get quite a lot of mileage out of merely
> rate limiting and fq_codeling at the airplane itself.
>
> I note that we have not extensively tested fq_codel at the latencies
> typically experienced here and probably should!
>
> I also tend to wish that streaming video had got it's own control port
> rather than being layered over 80 and 443.
>
> lastly... I do appreciate very much your mention of me, but if you
> could expand that bit to say any of the bufferbloat crew - all of us
> seem to be looking for work, or distracted by other work. In my case I
> am mostly now distracted by non-bufferbloat related, but paid work.
>
> The fact that I still have to rattle a tin cup to fix bufferbloat at
> this point is quite bothersome. With such an epidemic of a problem I
> really thought the world would have beat a path to our doors long,
> long ago, and/or start leveraging the plethora of information and code
> we have put online to go forth and deploy bufferbloat solutions,
> especially in extreme cases like aircraft, access in the third world,
> and in remote areas. Certainly the ubnt userbase jumped all over
> fq_codel...
>
>
> >
> >
> > _______________________________________________
> > Cerowrt-devel mailing list
> > Cerowrt-devel@lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> >
>
>
>
> --
> Dave Täht
>
> thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks
> _______________________________________________
> Cerowrt-devel mailing list
> Cerowrt-devel@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/cerowrt-devel
>