Re: Cogent admits to QoSing down streaming

[Blake Hudson <blake () ispn net>]

Owen, should providers be able to over subscribe their networks? If so, 
at what tier level (tier 1, 2, 3, residential ISP)? Is it acceptable for 
a provider to permit frequent congestion if they choose to? Or should 
they be forced to take action that may (potentially) lead to increased 
customer rates or reduced customer bandwidth?

I do think that Cogent's customers likely expect to receive their full 
subscription rate, without congestion, nearly 100% of the time (at least 
within the Cogent network). This would mean that having congestion is a 
problem and QoS is not a solution to congestion. However, I don't think 
all customers of all IP transit providers have this expectation. For 
example, residential customers may be happy with "up to X Mbps" if the 
costs associated are 1/10th that of a "guaranteed X Mbps" service. This 
is essentially the difference between "Bronze" and "Silver" service 
levels. As long as market choice exists, I see no problem with a 
provider choosing to operate a slow, inconsistent, or unreliable network 
as long as the internet as a whole, being a piece of critical 
communications infrastructure, remains available and reliable. 
Effectively, this would mean that tier 1 and 2 transit providers 
(including Cogent) would need to be consistent and reliable. While 
regional transit providers and ISPs would be given much more 
flexibility. Regardless, I think letting transit providers/ISPs pick 
winners and losers is a losing strategy in the long term.

--Blake

Owen DeLong wrote on 11/6/2014 12:10 PM:
> The way I read it was that Cogent actually made things look artificially better for M-Labs while simultaneously making 
> it much worse for one subset of their users and somewhat better for others.
>
> I would suggest that if we get the educational process right, we should be able to explain that the point where you’re 
> having to select traffic to prioritize is the point where your network is inadequate to the task at hand and should be 
> upgraded.
>
> I don’t see any reason we shouldn’t be able to use this article as a prime example of a provider doing the wrong thing 
> instead of fixing the real problem — Congestion at exchange points.
>
> Owen
>
> > On Nov 6, 2014, at 8:12 AM, Patrick W. Gilmore <patrick () ianai net> wrote:
> >
> > <http://blog.streamingmedia.com/2014/11/cogent-now-admits-slowed-netflixs-traffic-creating-fast-lane-slow-lane.html>
> >
> > This is interesting. And it will be detrimental to network neutrality supporters. Cogent admits that while they were 
> > publicly complaining about other networks congesting links, they were using QoS to make the problem look worse.
> >
> > One of the problems in "tech" is most people do not realize tone is important, not just substance. There was - still 
> > is! - congestion in many places where consumers have one or at most two choice of providers. Even in places where there are two 
> > providers, both are frequently congested. Instead of discussing the fact there is no functioning market, no choice for the 
> > average end user, and how to fix it, we will now spend a ton of time arguing whether anything is wrong at all because Cogent did 
> > this.
> >
> > Wouldn't you rather be discussing whether 4 Mbps is really broadband? (Anyone else have flashbacks to "640K is enough for 
> > anyone!"?) Or how many people have more than one choice at 25 Mbps? Or whether a company with a terminating access monopoly can 
> > intentionally congest its edge to charge monopoly rents on the content providers their paying customers are trying to access? I know I 
> > would.
> >
> > Instead, we'll be talking about how things are not really bad, Cogent just made it look bad on purpose. The subtlety of "it 
> > _IS_ bad, Cogent just shifted some of the burden from VoIP to streaming" is not something that plays well in a 30 second sound 
> > bite, or at congressional hearings.
> >
> > It's enough to make one consider giving up the idea of having a functioning, useful Internet.
> >
> > --
> > TTFN,
> > patrick