[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.