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.