Many players make up application performance (was Re: Richard Bennett, NANOG posting, and Integrity)
On 7/28/14, 5:35 PM, "Jim Richardson" <weaselkeeper@gmail.com> wrote:
I pay for (x) bits/sec up/down. From/to any eyecandysource. If said eyecandy origination can't handle the traffic, then I see a slowdown, that's life. But if <$IP_PROVIDER> throttles it specifically, rather than throttling me to (x),I consider that fraud.
I didn't pay for (x) bits/sec from some whitelist of sources only.
Along with paying <$IP_PROVIDER> for (x) bits/sec up/down, you are also paying (or the product of advertising) eyecandysource to deliver a service (w/ a level of quality). <$IP_PROVIDER> plays a big role in delivering your *overall* Internet experience, but eyecandysource plays an even bigger role delivering your *specific* eyecandy experience. If eyecandystore has internal challenges, business negotiation/policy objectives, or uses poor adaptive routing path decisions, this has a direct and material impact to your *specific* eyecandy experience (and some have found fixable by hiding your source IP with a VPN). While ISPs do play a big role in this, people tend to miss eyecandystore decisions (and business drivers) as a potential factors in isolated application performance issues.
What I would like to see is someone who sets up a VPN that has an endpoint path that¹s the same as NetFlix. If their streaming performance improves that would be very telling. Heck you could use 2 machines and do a side by side. However I doubt Level3 is going to sit there and lie about their connection to Verizon being overloaded, and for Verizon to do any kind of meaningful QOS it would require an effort on the Level3 side of the connection as well. On 7/29/14, 8:33 AM, "McElearney, Kevin" <Kevin_McElearney@cable.comcast.com> wrote:
On 7/28/14, 5:35 PM, "Jim Richardson" <weaselkeeper@gmail.com> wrote:
I pay for (x) bits/sec up/down. From/to any eyecandysource. If said eyecandy origination can't handle the traffic, then I see a slowdown, that's life. But if <$IP_PROVIDER> throttles it specifically, rather than throttling me to (x),I consider that fraud.
I didn't pay for (x) bits/sec from some whitelist of sources only.
Along with paying <$IP_PROVIDER> for (x) bits/sec up/down, you are also paying (or the product of advertising) eyecandysource to deliver a service (w/ a level of quality). <$IP_PROVIDER> plays a big role in delivering your *overall* Internet experience, but eyecandysource plays an even bigger role delivering your *specific* eyecandy experience. If eyecandystore has internal challenges, business negotiation/policy objectives, or uses poor adaptive routing path decisions, this has a direct and material impact to your *specific* eyecandy experience (and some have found fixable by hiding your source IP with a VPN).
While ISPs do play a big role in this, people tend to miss eyecandystore decisions (and business drivers) as a potential factors in isolated application performance issues.
On Tue, Jul 29, 2014 at 11:11 AM, Corey Touchet <corey.touchet@corp.totalserversolutions.com> wrote:
What I would like to see is someone who sets up a VPN that has an endpoint path that¹s the same as NetFlix. If their streaming performance improves that would be very telling. Heck you could use 2 machines and do a side by side.
Been done: http://arstechnica.com/information-technology/2014/02/netflix-slow-on-verizo... http://www.extremetech.com/extreme/186673-how-to-use-a-vpn-to-boost-your-net... http://www.techhive.com/article/2457642/how-a-netflix-subscriber-used-vpn-to... -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> Can I solve your unusual networking challenges?
It is common courtesy around these parts to not libel your customers, especially when they're paying you lots of money and making up 30% of your incoming traffic. That you're posting in "hypotheticals" does not mask your true messaging. Drive Slow, Paul Wall On Tue, Jul 29, 2014 at 2:33 PM, McElearney, Kevin <Kevin_McElearney@cable.comcast.com> wrote:
On 7/28/14, 5:35 PM, "Jim Richardson" <weaselkeeper@gmail.com> wrote:
I pay for (x) bits/sec up/down. From/to any eyecandysource. If said eyecandy origination can't handle the traffic, then I see a slowdown, that's life. But if <$IP_PROVIDER> throttles it specifically, rather than throttling me to (x),I consider that fraud.
I didn't pay for (x) bits/sec from some whitelist of sources only.
Along with paying <$IP_PROVIDER> for (x) bits/sec up/down, you are also paying (or the product of advertising) eyecandysource to deliver a service (w/ a level of quality). <$IP_PROVIDER> plays a big role in delivering your *overall* Internet experience, but eyecandysource plays an even bigger role delivering your *specific* eyecandy experience. If eyecandystore has internal challenges, business negotiation/policy objectives, or uses poor adaptive routing path decisions, this has a direct and material impact to your *specific* eyecandy experience (and some have found fixable by hiding your source IP with a VPN).
While ISPs do play a big role in this, people tend to miss eyecandystore decisions (and business drivers) as a potential factors in isolated application performance issues.
On Tue, Jul 29, 2014 at 10:33 AM, McElearney, Kevin <Kevin_McElearney@cable.comcast.com> wrote:
On 7/28/14, 5:35 PM, "Jim Richardson" <weaselkeeper@gmail.com> wrote:
if <$IP_PROVIDER> throttles it specifically, rather than throttling me to (x),I consider that fraud.
While ISPs do play a big role in this, people tend to miss eyecandystore decisions (and business drivers) as a potential factors in isolated application performance issues.
Hi Kevin, Network factors driving application performance issues are sometimes tricky but once the root cause is found, assigning fault is rarely mysterious. When everyone agrees the problem link is at that magical place, a mutually acceptable location where each network has been paid by their respective customer to get the packets there, one network is willing to swap those packets unconditionally and the other isn't, the fault is not mysterious at all. Regards, Bill Herrin -- William Herrin ................ herrin@dirtside.com bill@herrin.us Owner, Dirtside Systems ......... Web: <http://www.dirtside.com/> Can I solve your unusual networking challenges?
On Tue, 29 Jul 2014 14:33:28 -0000, "McElearney, Kevin" said:
(w/ a level of quality). <$IP_PROVIDER> plays a big role in delivering your *overall* Internet experience, but eyecandysource plays an even bigger role delivering your *specific* eyecandy experience. If eyecandystore has internal challenges, business negotiation/policy objectives, or uses poor adaptive routing path decisions, this has a direct and material impact to your *specific* eyecandy experience (and some have found fixable by hiding your source IP with a VPN).
Very true. But what we're discussing here is the *specific* case where eyecandystore's biggest challenge at delivering the experience is an external challenge, namely that $IP_PROVIDER's service sucks. It's particularly galling when $IP_PROVIDER's internal net is actually up to snuff, but they engage in shakedown tactics to upgrade peering points.
On 7/29/14, 12:45 PM, "Valdis.Kletnieks@vt.edu" <Valdis.Kletnieks@vt.edu> wrote:
On Tue, 29 Jul 2014 14:33:28 -0000, "McElearney, Kevin" said:
(w/ a level of quality). <$IP_PROVIDER> plays a big role in delivering your *overall* Internet experience, but eyecandysource plays an even bigger role delivering your *specific* eyecandy experience. If eyecandystore has internal challenges, business negotiation/policy objectives, or uses poor adaptive routing path decisions, this has a direct and material impact to your *specific* eyecandy experience (and some have found fixable by hiding your source IP with a VPN).
Very true. But what we're discussing here is the *specific* case where eyecandystore's biggest challenge at delivering the experience is an external challenge, namely that $IP_PROVIDER's service sucks. It's particularly galling when $IP_PROVIDER's internal net is actually up to snuff, but they engage in shakedown tactics to upgrade peering points.
There is a great analysis by Dr Clark (MIT) and CAIDA which shows while there are some challenged paths and relationships between providers, this is the exception vs the rule. Using the “exceptions" are business decisions. Performance is a two way street (as are shakedowns) - Kevin
The devil is in the details. Ken Florance (http://blog.netflix.com/2014/04/the-case-against-isp-tolls.html) paints a different picture in his blog, for example. As a manager at Comcast, can you refer the people on this list to any ISPs who do not have a history of congestion into your network? This question comes up about once a month, absent any good solutions, so insight would be appreciated. Drive Slow, Paul Wall On Tue, Jul 29, 2014 at 5:25 PM, McElearney, Kevin <Kevin_McElearney@cable.comcast.com> wrote:
On 7/29/14, 12:45 PM, "Valdis.Kletnieks@vt.edu" <Valdis.Kletnieks@vt.edu> wrote:
On Tue, 29 Jul 2014 14:33:28 -0000, "McElearney, Kevin" said:
(w/ a level of quality). <$IP_PROVIDER> plays a big role in delivering your *overall* Internet experience, but eyecandysource plays an even bigger role delivering your *specific* eyecandy experience. If eyecandystore has internal challenges, business negotiation/policy objectives, or uses poor adaptive routing path decisions, this has a direct and material impact to your *specific* eyecandy experience (and some have found fixable by hiding your source IP with a VPN).
Very true. But what we're discussing here is the *specific* case where eyecandystore's biggest challenge at delivering the experience is an external challenge, namely that $IP_PROVIDER's service sucks. It's particularly galling when $IP_PROVIDER's internal net is actually up to snuff, but they engage in shakedown tactics to upgrade peering points.
There is a great analysis by Dr Clark (MIT) and CAIDA which shows while there are some challenged paths and relationships between providers, this is the exception vs the rule. Using the “exceptions" are business decisions.
Performance is a two way street (as are shakedowns)
- Kevin
participants (6)
-
Corey Touchet -
Matt Palmer -
McElearney, Kevin -
Paul WALL -
Valdis.Kletnieks＠vt.edu -
William Herrin