Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

YouTube's road to HTTPS

youtube-eng.blogspot.com

Post reply on HN
Print view View original

31–40 of 97 posts

Re: YouTube's road to HTTPS

#31

Post by dublinben »

mhurron wrote: post #22
dublinben wrote: post #13

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. They rely on the content providers' own adaptive streaming technology to deliver the appropriate 480p video when presented with a constrained connection.

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

Re: YouTube's road to HTTPS

#32

Post by dyladan »

icebraining wrote: post #30
lqdc13 wrote: post #27

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.

Why not limit the bandwidth per user instead? Youtube itself will auto-adjust quality based on connection speed.

Not sure about other services but at least GoGo was limited to about 500kbps per user last I heard.

Re: YouTube's road to HTTPS

#33

Post by rhino369 »

dublinben wrote: post #31
mhurron wrote: post #22

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.

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.

Re: YouTube's road to HTTPS

#34

Post by acdha »

icebraining wrote: post #30
lqdc13 wrote: post #27

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.

Why not limit the bandwidth per user instead? Youtube itself will auto-adjust quality based on connection speed.

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.

Re: YouTube's road to HTTPS

#35

Post by acdha »

TD-Linux wrote: post #9
JBiserkov wrote: post #4

Earlier quoted context omitted.

Attempting to inject adds? Reduce the size by applying JPEG compression? :)

When I had Sprint, they did in fact scale down and recompress all images in lower quality JPEG. Some carriers even attempt to realtime transcode video into a lower bitrate. The implementations of this are universally poor and produce rather broken files.

The most common implementation of this appears to be from a company called Bytemobile which also injects some pretty buggy JavaScript into HTML content.

The good news is that you can disable all of their degradation by adding "no-transform" to your Cache-Control headers:

https://kornel.ski/en/proxies

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

Re: YouTube's road to HTTPS

#37

Post by jasonuhl »

mikeash wrote: post #23
mholt wrote: post #18

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.

TCP already covers that sort of thing. What HTTPS adds is integrity checks against an intelligent attacker, not just random natural interference.

TCP only gives you 16 bits of checksum, which is really not enough. I used to work for a CDN which served downloads over HTTP, and when the object size grew to a few gigabytes a non-negligible percentage of users ended up with corruption.

The SSL MAC is valuable even in the absence of enemy action.

Re: YouTube's road to HTTPS

#38

Post by aw3c2 »

lqdc13 wrote: post #27
kbenson wrote: post #6

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.

> One person watching HD cat videos is going to consume more bandwidth than 20 people doing work.

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!

Re: YouTube's road to HTTPS

#39

Post by mdani »

acdha wrote: post #34
icebraining wrote: post #30

Earlier quoted context omitted.

Why not limit the bandwidth per user instead? Youtube itself will auto-adjust quality based on connection speed.

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 detect a HTTP session as video and just throttle that session.

Re: YouTube's road to HTTPS

#40

Post by amscanne »

dublinben wrote: post #31
mhurron wrote: post #22

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.

What's "artificial" shaping?

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.

Post reply on HN