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