[Cerowrt-devel] SInce I mentioned this crew's work in a post, I don't want anyone to be surprised.
jg at freedesktop.org
Tue Jan 6 14:50:09 EST 2015
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.
On Tue, Jan 6, 2015 at 2:37 PM, Dave Taht <dave.taht at gmail.com> wrote:
> On Tue, Jan 6, 2015 at 9:26 AM, <dpreed at 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.
> ) 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
> > _______________________________________________
> > Cerowrt-devel mailing list
> > Cerowrt-devel at lists.bufferbloat.net
> > https://lists.bufferbloat.net/listinfo/cerowrt-devel
> Dave Täht
> Cerowrt-devel mailing list
> Cerowrt-devel at lists.bufferbloat.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Cerowrt-devel