[toast0]

In part, because most video sites will adapt the stream to the achievable bandwidth.

In part, because if the throttle all bulk data transfers over some minimum size, all the time, most people are only going to notice on video streaming, since videos are the most frequent bulk transfers.

[zAy0LfpBZLC8mAC]

> In part, because most video sites will adapt the stream to the achievable bandwidth.

Why is that a reason to force them to use less than their fair share of available bandwidth?

> In part, because if the throttle all bulk data transfers over some minimum size, all the time, most people are only going to notice on video streaming, since videos are the most frequent bulk transfers.

How is that a reason for anything, and what is it actually supposed to be a reason for?

[toast0]

>> In part, because if the throttle all bulk data transfers over some minimum size, all the time, most people are only going to notice on video streaming, since videos are the most frequent bulk transfers.

>How is that a reason for anything, and what is it actually supposed to be a reason for?

I was unclear. I'm suggesting that carriers are in fact, throttling all bulk data, but reporting is focused on video. Allow a sizable burst of data at the beginning of a connection and then start rate limiting, and most people won't notice except for on videos.

This was probably the simplest, least noticable, least costly intervention to reduce peak congestion and provide a consistent experience across the carrier network.

Is it fair? Maybe, if applied to all traffic

Is it clear and transparent? No, clearly not.

Does it allow for the network to be used to capacity? No, not unless the limits were modulated based on current use, which doesn't seem to be the case.

Is it good for customers? Unclear -- to the extent you can watch good enough videos using less of your data quota, that might be a good thing; to the extent that you spend more time downloading updates, that's probably not good, but would need analysis of battery impact traded off with better push latency if the radio is kept on for other reasons. Also, to the extent that this throttling provides better availability in congested area, that's a plus for users.

[zAy0LfpBZLC8mAC]

> I was unclear. I'm suggesting that carriers are in fact, throttling all bulk data, but reporting is focused on video.

Seems unlikely to me, but who knows ...

> Also, to the extent that this throttling provides better availability in congested area, that's a plus for users.

If you are being throttled, that's obviously not increasing availability in any meaningful sense, so, no, it's not. What would be a plus for users would be adding capacity. Not performing the contractually agreed service is the exact opposite of "increasing availability".

Overall, the problem with all of this is that it borders on fraud. There would be no problem with selling low-bandwidth plans, if that is the only thing you can offer at economical prices. Or offering the user the choice to throttle certain services so as to conserve bandwidth. The problem is that carriers kinda-sorta sell a service and then don't do what they kinda-sorta promised. And a big part of the problem is that everyone frames this as "trying to help the customer by limiting abusers", or something similar, when really, the only abuser is the carrier selling a service they don't intend to perform, because they would have to spend money to do that.

The important part is not whether some traffic is throttled, the important part is who makes the decision as to what gets throttled. If I buy 1 Mb/s mobile IP access, and then the carrier throttles my connection to 1 Mb/s, that's my decision. If I buy "LTE full-speed IP access", and then the carrier throttles my videos to 1 Mb/s with no option to opt out, it is not.

[toast0]

> If you are being throttled, that's obviously not increasing availability in any meaningful sense, so, no, it's not. What would be a plus for users would be adding capacity. Not performing the contractually agreed service is the exact opposite of "increasing availability".

Adding capacity is easy to say, but can be hard to do. Where I live, the city council basically won't permit new towers; whatever licensed spectrum on the towers we have is the capacity.

Trying to frame this as a contractual issue is a losing battle. Nowhere ever did someone contractually promise you a meaningful speed to an unknown destination at a consumer approachable price. Certainly, it's not transparent, and that's reason to be upset.

[tlb]

In a world (like ours) with limited bandwidth, you sometimes want to limit flows in a way to produce the least harm. Throttling different streams has different effects on user happiness.

For instance, if you are 100 Mbits over capacity, you could either:

(a) Throttle 100 users Netflix streams, which drop from 1080p to 720p

(b) Throttle email, it backs up causing hour-long email delays.

One is obviously less harmful.

[zAy0LfpBZLC8mAC]

> In a world (like ours) with limited bandwidth

That is actually the first mistake in your argument in this context. The bandwidth limits in mobile networks are first and foremost an effect of decisions by the network operators, not an inherent property of the world.

> you sometimes want to limit flows in a way to produce the least harm. Throttling different streams has different effects on user happiness.

Well, maybe. But I would argue that that is both (a) prone to erroneous valuation, if only due to conflicts of interest, and (b) almost always only the case to any significant degree in very artificial scenarios, not in the real world.

> For instance, if you are 100 Mbits over capacity, you could either:

> (a) Throttle 100 users Netflix streams, which drop from 1080p to 720p

> (b) Throttle email, it backs up causing hour-long email delays.

> One is obviously less harmful.

Primarily, that's a nonsensical scenario. For one, you are never "over capacity". That's what capacity means: The maximum speed at which you can transfer data. You never transfer data faster than you can. You are only "over capacity" in the sense that the link is congested, but that isn't a data rate that you are "over the limit", it's just that the queue starts to grow.

But also, your scenario implies that throttling email more than its fair share somehow would cause "hour-long email delays". Now, I dunno, what would that look like? 100 users using netflix, ~ 10 Mb/s each, for a total of 1000 Mb/s, and one user sending emails at 1000 Mb/s, which would then lead to the email sender being throttled to 950 Mb/s under fair sharing, which ... still would not lead to anything remotely like "hour-long email delays", despite being a totally contrived scenario?

It looks more like you just made up one bad thing and one not so bad thing, and then noted that the worse thing is worse. Which is fine. But it is completely irrelevant to the discussion if you do not demonstrate how those two options are actually options in the same situation, and how they, respectively, compare to fair sharing.

[tlb]

It's an inherent property of the world that bandwidth is expensive, so it's always going to be limited.

There are two types of protocols: those that adjust the quantity of data sent depending on conditions, and those that don't. Streaming video does -- if throughput drops, it changes video encoding to send fewer bytes. Most other protocols don't -- they just get slow but they still need to send all the bytes eventually. There's a solid argument for throttling the first kind when congestion hits.

There's a huge literature on this. Start at https://en.wikipedia.org/wiki/Fairness_measure if you want to learn more.

[zAy0LfpBZLC8mAC]

> It's an inherent property of the world that bandwidth is expensive, so it's always going to be limited.

Which is about as vague as it can get.

To make things more concrete: What would a gigabyte of mobile traffic cost if network operators were to optimize for low per-GB cost?

> There are two types of protocols: those that adjust the quantity of data sent depending on conditions, and those that don't. Streaming video does -- if throughput drops, it changes video encoding to send fewer bytes. Most other protocols don't -- they just get slow but they still need to send all the bytes eventually. There's a solid argument for throttling the first kind when congestion hits.

Except: There really is not, especially not between customers, which is what this discussion is about.

It is not some random accident that video streaming happens to be the thing that adapts to available bandwidth: That is precisely because it eats so much bandwidth compared to everything else. Which also means that throttling it in favor of other applications between different customers is actually not really useful. If you have one customer that watches a video stream and one (comparable, end-user) customer sending emails, then the email user will pretty much always have lower bandwidth requirements than their fair share anyway.

Also, it simply is not up to you to decide what a customer should value. If you sell a customer a contract that promises a certain bandwidth that is sufficient for high quality video streaming, then it is your job to provide that bandwidth at any time, except for rare occasions when/where unexpected demand hits you. It is not up to you to decide that a low-quality stream ought to be good enough, or that someone else's emails are more important than their high-quality video stream, if they are paying you for the same level of service. If the customer thought that that would be good enough, they would have bought a lower-bandwidth plan. If you don't offer a lower-bandwidth plan, then that is your fault.

Congestion should never be a standard condition in your network, if it is, what you are doing is essentially fraud by selling people a service that you don't intend to perform. The fact that it might be technically impossible to perform the service doesn't change that, it's still your fault if you know that you can't perform the service, but you enter into contracts anyway. Congestion should be an exceptional condition, and as such should never be so massive as to have any advantage from using application-dependent throttling between customers.