* Re: [Cerowrt-devel] SInce I mentioned this crew's work in a post, I don't want anyone to be surprised.
2015-01-06 19:37 ` Dave Taht
@ 2015-01-06 19:43 ` David Lang
2015-01-06 19:50 ` Jim Gettys
2015-01-19 19:17 ` Aaron Wood
2 siblings, 0 replies; 5+ messages in thread
From: David Lang @ 2015-01-06 19:43 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1419 bytes --]
On Tue, 6 Jan 2015, Dave Taht 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!
does anyone know someone on a satellite connection? I think I know one person
who is.
David Lang
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [Cerowrt-devel] SInce I mentioned this crew's work in a post, I don't want anyone to be surprised.
2015-01-06 19:37 ` Dave Taht
2015-01-06 19:43 ` David Lang
@ 2015-01-06 19:50 ` Jim Gettys
2015-01-19 19:17 ` Aaron Wood
2 siblings, 0 replies; 5+ messages in thread
From: Jim Gettys @ 2015-01-06 19:50 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 3140 bytes --]
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
>
[-- Attachment #2: Type: text/html, Size: 4607 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: [Cerowrt-devel] SInce I mentioned this crew's work in a post, I don't want anyone to be surprised.
2015-01-06 19:37 ` Dave Taht
2015-01-06 19:43 ` David Lang
2015-01-06 19:50 ` Jim Gettys
@ 2015-01-19 19:17 ` Aaron Wood
2 siblings, 0 replies; 5+ messages in thread
From: Aaron Wood @ 2015-01-19 19:17 UTC (permalink / raw)
To: Dave Taht; +Cc: cerowrt-devel
[-- Attachment #1: Type: text/plain, Size: 996 bytes --]
On Tue, Jan 6, 2015 at 11:37 AM, Dave Taht <dave.taht@gmail.com> wrote:
>
> I also tend to wish that streaming video had got it's own control port
> rather than being layered over 80 and 443.
>
In my experience, that was due to the corporate firewalls' default rule of
disallowing outbound connections. Port 80 can be deep-packet-inspected to
confirm it's HTTP, and 443 can be confirmed to be SSL, and so everything
else was shut down. So everything had to be delivered over those, or it
failed. In my world, that means that IoT devices talking custom protocols
over SSL have to use 443 to the datacenters because the corporate firewall
people won't allow anything else out. And if you can't demo it from the
"guest" network at a company, you won't make any sales there.
OTOH, fq_codel should hash them out separately based on the destination IP
and source ports as separate connections. Not separable into a QoS bucket,
but at least able to pry apart the streams for fairness...
-Aaron
[-- Attachment #2: Type: text/html, Size: 1411 bytes --]
^ permalink raw reply [flat|nested] 5+ messages in thread