|
Nah, that mostly isn't really true. For one, internet service generally is and is accepted to be overbooked. Not to a degree that customers normally notice (well, it sometimes is, but that's not really acceptable), but there is no guarantee that the nominal bandwidth is available at all times to all customers, in particular on mobile networks. The burstiness of the traffic of individual users is not really a problem for network capacity planning, as a large enough collection of users will have a much smoother traffic pattern than any given individual. Yes, one user's file transfers throughout the day are very bursty. The combined file transfers of a few thousand users are not. What remains is variation throughout the day--but that also affects streaming services. When noone is transferring files, noone is listening to or watching streams either. So with or without zero rating, you still have to build more infrastructure than if the same amount of data were being transferred completely smoothly throughout the month. Also, if your goal were to smooth out traffic, certain file downloads should actually be treated preferentially--namely, file downloads scheduled for late at night. You should give people free podcatcher downloads at night, so people can download stuff to listen to during the day at night, when the network is otherwise idle, to shift load away from the day. But what I think really makes this a bad argument is the fact that this argument in no way is specific to the approach of treating certain service (operators) preferentially. If your goal is to incentivise smooth bandwidth utilization, there is no need to therefore require specific streaming technologies and a contract between the service and the ISP and all that--all you need to do is to say that bandwidth use below 256 kbit/s (or whatever the appropriate bandwidth is) is not counted against the cap, that's it. You simply put a price on the actual network load that you want to (dis-)incentivize and leave it to customers to decide how to make use of the resources you are selling them. There is no reason why spotify's 256 kbit/s needs to be treated differently than my own server's 256 kbit/s in order to price smoother network load cheaper than non-smooth load. If you want to make things more transparent for the customer, provide them with an app that shows them their current data rate, maybe with a switch that enables "safe mode" (i.e. limiting their data rate to what is not counted against the cap, maybe with some token bucket built in to not slow down occasional web page loads). Or, for that matter, if they were actually serious about the smooth load thing, they could create an internet standard that smart phones (or any other devices) could implement that would allow them to mark flows that are to be subjected to low-bandwidth shaping. Then, apps could potentially just request a "cheap, low bandwidth socket", and the operating system could make sure that on any ISP that supports a category of slow, cheap bandwidth, that socket's data transfer would be zero-rated, without any need to sign contracts between service providers and (thousands of) ISPs, without any discrimination against small services or self-hosted stuff. The collateral damage of the approaches that ISPs are taking is unnecessary for reaching those goals, and everything about how they do it tells you that that is fully intentional. |