> 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?!
Wow, what were carriers doing to the streams?!
1: Well, I'm assuming, but it seems likely this was the main reason.
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.
I find it unlikely that Linux, FreeBSD have gotten less efficient since then and the hardware has made enormous improvements, far in advance of the common uplink speed.
ISPs have it especially easy, because they can be assured of being able to distinguish traffic from a given user (hardware control of the medium). It's a bit harder in wireless scenarios, since the client can spoof multiple different IDs, but it's hard for them to keep open a TCP connection under those conditions.
Ideally, there would be a dynamic limit based on network utilization and type of content consumed.
Because that would require actual effort from ISPs, which would be in conflict with their current business practice that can be summarized as "to us, you are all equally worthless".
One HD stream probably uses more continuous bandwidth as those 20 people so just limit that. Allow bursts maybe.
> Prioritizing non-video content is challenging if all content is encrypted.
Good! It's none of their business what I am doing with my bandwidth!
> 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.
Why would you say this? Surveilling what URLs someone is accessing / content they are watching / books they're checking out of the library has been a major security issue, historically.
The biggest factor about surveillance is that you are rarely aware you're being surveilled. Direct evidence is rarely present.
Case in point, Michael Lewis's Flyboys. HFT trades intercepts weren't being overtly signalled, but were only evident when trades were structured such that they bypassed the opportunity to intercept intentions at the first market.
Some carriers even attempt to realtime transcode video into a lower bitrate. The implementations of this are universally poor and produce rather broken files.
If YouTube can't handle traffic shaping, Youtube is broken.
The average consumer ISP has an over subscription ratio of 70-to-1.
Unless you want to pay 70x as much for your "100mbit" connection, there are going to be times when packets get dropped.
Isn't it better to drop packets fairly among subscribers? No shaping would result in whoever is using the most dominating everyone else.
This basic principle is still neutral; you don't have to shape based on destination / content provider.
Your ISP doing traffic shaping is a question of if they should, not a technical question.
The good news is that you can disable all of their degradation by adding "no-transform" to your Cache-Control headers:
“The standard HTTP header Cache-Control: no-transform which tells proxies not to modify responses was respected by all proxies I've encountered. This is amazing! It wins an award in the "Best Supported Obscure Header" category.”
The SSL MAC is valuable even in the absence of enemy action.
In "Performance of Checksums and CRCs over Real Data" Stone and Partridge estimated that between 1 in 16 million and 1 in 10 billion TCP segments will have corrupt data and a correct TCP checksum. This estimate is based on their analysis of TCP segments with invalid checksums taken from several very different types of networks. The wide range of the estimate reflects the wide range of traffic patterns and hardware in those networks. One in 10 billion sounds like a lot until you realize that 10 billion maximum length Ethernet frames (1526 bytes including Ethernet Preamble) can be sent in a little over 33.91 hours on a gigabit network (10 * 10^9 * 1526 * 8 / 10^9 / 60 / 60 = 33.91 hours), or about 26 days over a T3.