That’s true, and it’s also true when Netflix buys a dedicated circuit to Comcast. Their traffic is no longer going over the other circuits.
Not saying it’s the right thing to do, but that it’s functionally the same.
It’s also functionally the same to say that any traffic not on the CDN is in a slow lane or being held ransom, in the sense that it will be congested until the publisher pays.
> It’s also functionally the same to say that any traffic not on the CDN is in a slow lane or being held ransom
You're confusing routes with endpoints. CDNs are endpoints--multiple endpoints containing the same data so that there is a much higher probability of having an endpoint close to any given user. The owner of the data has to do all the work of getting multiple copies of the data placed at all those endpoints, making sure they're all in sync, etc. But the data traveling from endpoint to endpoint--from the nearest CDN node to the user--is not privileged over any other data.
What the net neutrality debate is about is the ISPs wanting to control routes--i.e., to be able to say that some data traveling over a given route from one endpoint to another endpoint gets to travel faster than other data traveling over the same route. CDNs don't do that.
What Netflix bought from Comcast is sort of in between. It's like a CDN in that Netflix still has to do the work of placing multiple copies of their content at different endpoints in different locations; but it's also like the ISP route control scheme in that Netflix' data gets a privileged route from their endpoints to Comcast users, a route that non-Netflix data from endpoints that are similarly situated does not get, because non-Netflix data can't travel through the special connection points that Netflix now has with Comcast. Normal CDNs don't do that either.
A CDN is a route, is my contention. Its value is being closer to the user.
CDNs are a good thing. But they are networks like any other, the difference being that the nodes are smart enough for to re-request data they already have. CDN nodes should be understood as caching routers.
Being closer to the user – the CDN’s value – rests in having a better position vis-à-vis the last-mile network. A better position vis-à-vis the last-mile network is what Netflix bought.
> A CDN is a route, is my contention. Its value is being closer to the user.
Being an endpoint that is closer to the user is not the same as being a route between that endpoint (or any other endpoint) and the user.
> CDN nodes should be understood as caching routers.
In some respects, yes. But in other important respects, no. For example, CDN nodes do not route traffic that does not have that node as either a source or a destination. The fact that the content at that node ultimately comes from another source does not change that; it simply means that some of the traffic to and from the CDN node is to and from the ultimate source of the content. It's still not at all the same as routing traffic to and from arbitrary endpoints.
> Being closer to the user – the CDN’s value – rests in having a better position vis-à-vis the last-mile network. A better position vis-à-vis the last-mile network is what Netflix bought.
You're conflating two different ways of taking a "position" in the network. A CDN takes advantage of the existing network and the existing routes to place copies of content closer to users. It can only use the existing "positions" in the network, not create new ones.
The Netflix deal created a new privileged route that didn't exist before, for Netflix content going to Comcast users only. So the "position" Netflix traffic is now in with respect to Comcast users didn't even exist before the deal.
How? Adding any new node to the Internet does create new routes to and from that node, but that doesn't give those routes any privileges over other routes.
> Netflix did buy a new route, replacing the one they were previously buying from Cogent.
And the difference between the new one and the old one is that the new one only carries Netflix traffic, and only goes to Comcast customers. That is what makes it privileged, and what CDNs in general, including the CDN Netflix was previously using to distribute its traffic to Cogent, do not do.
CDNs operate servers, not routers. The servers can be located in data centers with easy connections to ISPs and transit providers, but their traffic still doesn't get privileged over other traffic coming in to the networks of those ISPs and transit providers. There are no separate routes that CDN traffic takes to a user's computer, that other traffic from sources in the same data center, or going through routers in the same data center, can't take.
I think you're focusing too much on the technical implementation. I agree with the parent that a CDN effectively carries traffic from a content provider to the end user. Sure it does it in bigger chunks, and uses existing network connections. But the end result is still "pay more for faster access", and isn't that exactly what net neutrality is against?
> I think you're focusing too much on the technical implementation
I'm focusing on the functionality that's being implemented, which is what the poster I was responding to said was important. Having privileged routes is different functionality from having multiple hosts that all have copies of the same data.
> a CDN effectively carries traffic from a content provider to the end user.
But so does a non-CDN. So does any route on the Internet. The only difference with a CDN is that the content provider has paid for more servers to host multiple copies of the data. But the money is for those multiple copies, not for giving any specific copy a privileged route to certain users. As above, that's a functional difference.
Here's another way of seeing the functional difference. Say I use two online services, A and B. A is served using a global CDN. B is served using a privileged network with my current ISP. Now I change ISPs to one that service B isn't paying for privileged access to. I see no difference in performance with service A, but a big difference in performance with service B. So service A using a CDN doesn't lock me in to a specific ISP; but service B paying for privileged routes does.
> the end result is still "pay more for faster access"
No, it's "pay more for multiple copies of your data". It's not "pay more to have your data go over a quicker route from the same place".
> isn't that exactly what net neutrality is against?
No, net neutrality is not against "pay more for faster access", like service A above. It's against "pay more for privileged access to an ISP's users", like service B above.
No, as far as I can tell the incentives in the two scenarios are very different.
The transparence on what is being payed for and why some sites are fast and some are slow is not the same for Comcast's subscribes in the two scenarios either.
Not saying it’s the right thing to do, but that it’s functionally the same.
It’s also functionally the same to say that any traffic not on the CDN is in a slow lane or being held ransom, in the sense that it will be congested until the publisher pays.