I’ve tried joining Stream On (the term for T-Mobile#s Binge On and Music Freedom outside the US), but the requirements are insane.

4 weeks before I make any changes to any service I run via Stream On, I need to inform T-Mobile, and they have to approve the changes, or can end Stream On immediately.

All Stream On content needs to run via separate hostnames, and has to transmit the hostname in cleartext.

I have to be using forms of adaptive streaming, the bandwidth will be limited during this so that the user at most will be able to watch 480p videos.

50'000 EUR fine for each violation from my side, no fines if T-Mobile just kicks me out.

And so on and so on. It’s ridiculous.

Give me a single form where I enter a URL, and it’ll be zero-rated – or don’t zero-rate anything.

> T-Mobile's stated policy is to get as many music streaming services as possible covered.

While that may be a stated policy, it is also obviously a lie.

Obviously, they only want specific kinds of services covered, or else they would just drop this crap in the first place, as that is the only and totally straightforward way to make sure that all services are covered.

If I run a bittorrent-based streaming service, they do not want to cover that. It's pure propaganda that they want to cover as many services as possible.

I believe I read that participating providers are identified by IP address. Wouldn't that be technically unfeasible for a bittorrent-based provider?

So?! Yes, it probably would be ... but how is it my responsibility that they chose to identify services in a manner that inherently discriminates against certain services? If it was true that they intended to cover as many services as possible, they would not have chosen an identification method that obviously doesn't work for some services ... or for that matter, not introduced any distinction at all, and instead just increased the data cap, which would automatically work for all services.

Let S/D mean a service that offers a speed S mbit/sec with a data cap of D GB per month.

Let P(S,D) be the resources required to support that service. In general, for positive x, both of the following are true: (1) P(S+x,D) > P(S,D), and P(S,D+x) > P(S,D).

Let's say a particular ISP has everyone on a 40/10 plan, so they need P(40,10) resources.

Now suppose they decide to offer something like Music Freedom. A person streaming a 256 kbit/s stream 24/7 would use about 90 GB/month.

The resources required to support their customers are now approximately P(40,10) + P(1/4,90).

If instead they just raise the cap of everyone by 90, the resources required are P(40,100), which is about the same as P(40,10) + P(40,90) [1].

The general cap increase will use around P(40,90) - P(1/4,90) more resources than the Music Freedom approach.

In general, for a given total amount of data transferred per month, the more smoothly that data is spread throughout the month, the less resources are needed to handle it.

Music streaming is both smooth and does not require much speed, so doesn't require much additional resources. Streaming of video requires more, because it needs more speed, but it is still less than is required to support the same total amount of data as arbitrary files downloads, because arbitrary file downloads don't have a built in rate limit.

[1] Not quite. I don't think it is quite true that P(S,D1) + P(S,D2) = P(S,D1+D2). I think the combined will be little less than the sum of the parts. That's because the resources needed are a function of the average data used, the variation in that, and how often you can have slowdowns due to congestion without getting in trouble with regulators. So I think it is like adding distributions...the variation in the combined will be less than the sum of the variations in the individual distributions (I think...)

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.