YouTube's road to HTTPS • Hacker News Board

Re: YouTube's road to HTTPS

#21

Post by ianlevesque » Mon, Aug 01, 2016, 7:20 PM UTC

dublinben wrote: post #13

TD-Linux wrote: post #9

Earlier quoted context omitted.

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

Not ideal but that's a lot less intrusive.

Re: YouTube's road to HTTPS

#22

Post by mhurron » Mon, Aug 01, 2016, 7:20 PM UTC

dublinben wrote: post #13

TD-Linux wrote: post #9

Earlier quoted context omitted.

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

Re: YouTube's road to HTTPS

#23

Post by mikeash » Mon, Aug 01, 2016, 7:22 PM UTC

mholt wrote: post #18

coob wrote: post #2

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

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

Re: YouTube's road to HTTPS

#24

Post by drzaiusapelord » Mon, Aug 01, 2016, 7:23 PM UTC

coob wrote: post #2

> 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 imagine this was a snarky comment about services like T-mobile's binge. They limit video 720p or 480i at a moderate bitrate for mobile. Its supposed to be opt-in but I wouldn't be surprised if many mobile providers peppered the video stream with errors to knock down costly high-bitrate 1080p streams.

Re: YouTube's road to HTTPS

#25

Post by drzaiusapelord » Mon, Aug 01, 2016, 7:28 PM UTC

JoshTriplett wrote: post #3

> 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 two ago, these were on shelves in the US at budget places like Cricket. I think almost 10% of Androids in the wild still don't support 1.2. Maybe more considering Google has limited snooping abilities in China and may not fully know the extent of these installs.

IE7/IE8/IE9 have a combined global marketshare of about 8% also.

Re: YouTube's road to HTTPS

#26

Post by Thaxll » Mon, Aug 01, 2016, 7:34 PM UTC

coob wrote: post #2

> 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?!

Remind me the madness that mobile carrier are doing to the TCP stack.

Re: YouTube's road to HTTPS

#27

Post by lqdc13 » Mon, Aug 01, 2016, 7:36 PM UTC

kbenson wrote: post #6

coob wrote: post #2

> 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?!

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.

Re: YouTube's road to HTTPS

#28

Post by nandhp » Mon, Aug 01, 2016, 7:36 PM UTC

drzaiusapelord wrote: post #25

JoshTriplett wrote: post #3

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

Android 2.3 doesn't even support SNI for virtual hosts on SSL.

Re: YouTube's road to HTTPS

#29

Post by drewg123 » Mon, Aug 01, 2016, 7:37 PM UTC

It would be interesting to know how much overhead HTTPS added for them. Eg, a comparison of CPU usage between HTTP and HTTPS on the server side, whether or not they are using hardware offloads, etc.

Netflix has some papers about their experience transitioning to HTTPS:

https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf https://people.freebsd.org/~rrs/asiabsd_tls_improved.pdf

However, I expect the YouTube workload would be vastly different from the Netflix workload due to the sheer size of the YouTube catalog.

Re: YouTube's road to HTTPS

#30

Post by icebraining » Mon, Aug 01, 2016, 7:40 PM UTC

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.

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