41–50 of 97 posts
> We found that HTTPS improved quality of experience on most clients: by ensuring content integrity, we virtually eliminated many types of streaming errors Wow, what were carriers doing to the streams?!
I grew up in rural Iowa with a poor Internet connection (satellite) that dropped packets if there were thick clouds, any snow or rain, even wind sometimes. Integrity checks would have helped a lot.
Earlier quoted context omitted.
It's long been known that some carriers purposefully degraded quality of youtube to keep from saturating their interconnections. That's the reason[1] behind the Google Video Quality Report[2]. Youtube does (did?) redirect you to a comparison of how well your ISP streamed content compared to others when there were streaming problems in some cases to combat this. 1: Well, I'm assuming, but it seems likely this was the…
Degrading video quality is not a bad idea if you have limited bandwidth. This would help in cases such as airplane flights. One person watching HD cat videos is going to consume more bandwidth than 20 people doing work. Now, assuming bandwidth increase is difficult to achieve, they would be forced to keep increasing the price instead. Prioritizing non-video content is challenging if all content is encrypted.
> Now, assuming bandwidth increase is difficult to achieve, they would be forced to keep increasing the price instead.
And they should. That ISPs commonly use deceptive practices in pricing and delivering service is not a good thing. It reduces market information There should be much more granular pricing based on what's actually delivered, but the major ISPs don't want to go that way because then they would actually have to account for how what they deliver so often falls below what they market.
For example, when I moved into my brand new built house a couple years back and got a 25 Mbit Comcast connection set up, the following conversation happened:
Installer: Wow, you have the best signal I've every seen actually.
Me: Really? That's good. So what throughput am I seeing?
Installer: Let me check. (Installer does a speed/circuit test). About 14 Mbit.
Me: Didn't I order 25 Mbit?
Installer: Yes, but lots of things can affect that, such as line quality...
Me: (Having worked at a local ISP multiple times in the past for years, cuts him off, realizing the futility of this conversation). Okay, that's fine.
In what reality do "the best signal I've ever seen" and 56% of the advertised throughput coincide? (this was not because the connection was overused by others in the neighborhood either, it was fairly consistent at 14 Mbit).
> This would help in cases such as airplane flights. One person watching HD cat videos is going to consume more bandwidth than 20 people doing work.
So would separate tiers of connectivity. If you are doing business, you may be happy with a guaranteed minimum throughput, while other people (such as those streaming) might be fine to take up the slack or excess (since you can cache future video). We've had this for a long time through QoS.
> Prioritizing non-video content is challenging if all content is encrypted.
So don't prioritize based on content, prioritize based on connection.
Earlier quoted context omitted.
If your ISP applies artificial traffic shaping, your ISP is broken.
I should be able to turn it off, but I like that tmo throttles my video. I only get 2.5 gb, I don't need 1080p.
Earlier quoted context omitted.
I grew up in rural Iowa with a poor Internet connection (satellite) that dropped packets if there were thick clouds, any snow or rain, even wind sometimes. Integrity checks would have helped a lot.
The worst is when you hit bandwidth caps and they cut you off. Gotta love background downloads...
Earlier quoted context omitted.
Exactly – this is both easier to implement and has the advantage of not incentivizing people to use something like a VPN to get more bandwidth at the expense of everyone else.
Per user limits are not easy to implement, maybe easier to visualize - consider that there are a bunch of packet gateways sitting behind a load balancer and each HTTP session may end up on a different server. There is no entity that counts the live bandwidth usage on a per user basis, let alone control it. Billing and metering is done on a session basis through logs. So from T-Mo's point of view it is much easier to…
Earlier quoted context omitted.
Degrading video quality is not a bad idea if you have limited bandwidth. This would help in cases such as airplane flights. One person watching HD cat videos is going to consume more bandwidth than 20 people doing work. Now, assuming bandwidth increase is difficult to achieve, they would be forced to keep increasing the price instead. Prioritizing non-video content is challenging if all content is encrypted.
The problem here is from who's perspective is there "limited bandwidth"? To the ISP there is limited bandwidth available, but to the customer they are having the service they pay for purposefully degraded because the ISP doesn't want to deliver on what they've marketed. > Now, assuming bandwidth increase is difficult to achieve, they would be forced to keep increasing the price instead. And they should. That ISPs com…
Earlier quoted context omitted.
> The more modern implementation of this (I'm looking at you, T-Mobile) is just to throttle all connections to content providers. If YouTube can't handle traffic shaping, Youtube is broken.
If your ISP applies artificial traffic shaping, your ISP is broken.
Your ISP doing traffic shaping is a question of if they should, not a technical question.
Earlier quoted context omitted.
Exactly – this is both easier to implement and has the advantage of not incentivizing people to use something like a VPN to get more bandwidth at the expense of everyone else.
Per user limits are not easy to implement, maybe easier to visualize - consider that there are a bunch of packet gateways sitting behind a load balancer and each HTTP session may end up on a different server. There is no entity that counts the live bandwidth usage on a per user basis, let alone control it. Billing and metering is done on a session basis through logs. So from T-Mo's point of view it is much easier to…
> In short, some devices do not fully support modern HTTPS. I'd love to know which devices, and what "modern HTTPS" features they don't support.
Its only fairly recently that Android got TLS 1.2 support with 4.1 in 2012. The problem is that for years budget Chinese android phones were shipping with 2.3, which was very light on resources and good for low powered phones with minimal ram. I believe this changed with an effort to use less ram and cpu with 4.4 or 5.0, but by then millions of these phones were sold and are still out there. Heck, up until a year or…
Not just budget Chinese phones. Low-end Samsung phones and such, too.