Re: [Cerowrt-devel] SInce I mentioned this crew's work in a post, I don't want anyone to be surprised.
On Tue, Jan 6, 2015 at 11:37 AM, Dave Taht 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 ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] SInce I mentioned this crew's work in a post, I don't want anyone to be surprised.
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 wrote: > On Tue, Jan 6, 2015 at 9:26 AM, 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 > ___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] SInce I mentioned this crew's work in a post, I don't want anyone to be surprised.
On Tue, 6 Jan 2015, Dave Taht wrote: On Tue, Jan 6, 2015 at 9:26 AM, 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___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
Re: [Cerowrt-devel] SInce I mentioned this crew's work in a post, I don't want anyone to be surprised.
On Tue, Jan 6, 2015 at 9:26 AM, 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
[Cerowrt-devel] SInce I mentioned this crew's work in a post, I don't want anyone to be surprised.
[ GoGo does not need to run “Man in the Middle Attacks” on YouTube ]( http://www.reed.com/blog-dpr/?p=174 )___ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel