Wireless is a medium that is severely limited because of the laws of physics. I 100% support QoS.
And by QoS I don't mean limiting video even if there's available bandwidth, I mean limiting it if other people are trying to use their connections reasonably.
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.
> 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?
>> 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.
> 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.
> 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.
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.
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.
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.
> 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.
I'm not sure what your question really is?! Is it whether I would want to buy an internet connection that's too slow for watching most video? Or whether I would want an internet connection that is too slow for watching most video to be offered on the market for people to buy? Or ... what?
Because in case of congestion the user watching video is abusing the system. It's like going to a congested public road with a convoy of lorries just because you can. Really, don't be a dick.
Because in case of congestion (let's say everybody gets allotted 50 KB/s) you can't even watch video. Dozens of users trying to watch video at 50 KB/s aren't even watching video; they're just launching a DDoS attack. I'd be very happy to throttle them to 1 KB/s so I don't have to wait 10 seconds to receive a picture through Whatsapp.
You're arguing against the laws of physics here, and you're arguing that stupid users should be able to screw everybody else. No thanks.
> Because in case of congestion (let's say everybody gets allotted 50 KB/s) you can't even watch video.
You can watch video at 500 kbps perfectly fine.
> Dozens of users trying to watch video at 50 KB/s aren't even watching video; they're just launching a DDoS attack.
So, you are saying the problem is with people who can't watch video, but do watch video anyway, despite the impossibility? Or are you saying that people who can't watch video, and therefore don't watch video, are congesting the network by not watching video? I can't really figure out what your claim even is.
> I'd be very happy to throttle them to 1 KB/s so I don't have to wait 10 seconds to receive a picture through Whatsapp.
OK, I understand that you would like to get preferential treatment. That's fine, but does not particularly convince me.
> You're arguing against the laws of physics here,
Which law of physics exactly?
> and you're arguing that stupid users should be able to screw everybody else. No thanks.
How is getting the same amount of resources as everybody else for paying the same price as everybody else "screwing everybody else"?
Really, it seems to me like you are simply repeating a completely unjustified claim over and over in different wording ... you might want to consider that repeating a claim does not make it more convincing, especially if you don't address objections.
>You're arguing against the laws of physics here and you're arguing that stupid users should be able to screw everybody else. No thanks.
i think there is a misunderstanding here.
he's not arguing that ISPs shouldn' be able to bandwidth-discriminate based on customer. He's arguing that they shouldn't be able to discriminate on the type of data. what would it matter to the other users if they were slowing down the network by html5 video, VNC, or playing a game over TCP?
I don't know a lot about networks, but i think a potential solution could be to discriminate between high-bandwidth and low-latency transmissions. For a video game or something you would want to have low latency, but you wouldn't need a lot of bandwidth. on the other hand, video streaming requires a lot of bandwidth but doesn't depend so much on latency as long as it has a big enough cache. images are probably somewhere in the middle. this would allow low-bandwidth applications to be prioritized.
> this would allow low-bandwidth applications to be prioritized.
That is a completely different kind of "prioritization" than what we are talking about here, though.
In particular, this "prioritization of low-bandwidth applications" does not in any way need to be aware of applications. All you need to do is to do fair link scheduling over all customers on a given link with some sort of token bucket per customer that allows short bursting. That way, if there is a customer that's been idle for a few minutes, say, they'll be able to transfer at, say, ten times the fair average rate for a few seconds, while other customers are slowed down proportionally, thus providing them with low latency. But that does not imply a higher average rate, nor a distinction of video vs. non-video, or anything like that. On average, every customer on a congested link would still be getting the exact same bandwidth, just as a constant low-bandwidth stream for some and as a series of short, fast bursts for others.
What tcxgy is arguing for is that if you are streaming video (or whatever other application that he doesn't like), then you should only be getting 2% of the average bandwidth compared to someone who is using an application he approves of. So, if you are constantly posting high-resolution pictures (something that he seems to approve of) at an average of 50 kB/s, that should get 50 kB/s, but if you are watching a 25 kB/s video stream of some sort, that should be throttled to 1 kB/s, because otherwise it's supposedly violating some laws of physics, and it's abusive to use half the bandwidth for video, and whatever other nonsense arguments he has come up with so far.
If the customer specifies QoS, why not? There are 6 reserved bits after HLEN in a TCP packet header, which could be used to annotate the priority of the stream - one for low-latency but also low bandwidth (=Whatsapp, messengers, gaming, VoIP), and one for bulk transfers (=high latency acceptable, high data volume).
Default would be the first so that networks may only have special treatment for apps that explicitly opt in to say "i'm ok to wait a bit" like Netflix, Youtube and friends.
And by QoS I don't mean limiting video even if there's available bandwidth, I mean limiting it if other people are trying to use their connections reasonably.