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

51–60 of 97 posts

Re: YouTube's road to HTTPS

#51

Post by lqdc13 »

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.

Let's say there are only 2 users using it. Then a lot of bandwidth would go unused if each user has a hard cap.

Ideally, there would be a dynamic limit based on network utilization and type of content consumed.

Re: YouTube's road to HTTPS

#52

Post by mey »

munificent wrote: post #19
TD-Linux wrote: post #11

Earlier quoted context omitted.

At least they didn't watch anything embarassing. My Youtube recommendations page is a dumpster fire.

TD-Linux: Hacker News Commenter - Last watched "Relaxing Background Videos Volume IIV: 4 Hours of a Peaceful Dumpster Fire (with sound)".

I've watched worse, such as 10 hour loops

Re: YouTube's road to HTTPS

#53

Post by zyxley »

semi-extrinsic wrote: post #46
kbenson wrote: post #42

Earlier quoted context omitted.

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…

FWIW, every time (about 6 times in 3 years I think) I've complained about slow connections to my ISP, with documentation from speedtest.net that I'm getting less bandwidth than promised, they've given me that month free of charge.

Sounds like there's some room here for a service that does speed tests and files complaints each month automatically.

Re: YouTube's road to HTTPS

#54

Post by pki »

iptables wrote: post #36

> You watch YouTube videos on everything from flip phones to smart TVs what year is this?!

I am less curious about the year and more curious as to how the hell flip phones are rendering video. Like 64p 3GPP or something realtime transcoded?

Re: YouTube's road to HTTPS

#56

Post by dawnerd »

drzaiusapelord wrote: post #24
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.

Opt in? It was opt out unless it changed very recently. I had a call with their corp office to plea why my plex server should also qualify but they said it wouldn't.

Re: YouTube's road to HTTPS

#57

Post by semi-extrinsic »

zyxley wrote: post #53
semi-extrinsic wrote: post #46

Earlier quoted context omitted.

FWIW, every time (about 6 times in 3 years I think) I've complained about slow connections to my ISP, with documentation from speedtest.net that I'm getting less bandwidth than promised, they've given me that month free of charge.

Sounds like there's some room here for a service that does speed tests and files complaints each month automatically.

Yeah, I thought about it, but we recently got the decent-speed option included almost-free with our cable TV (15 mbps for $4/month), so I couldn't be bothered anymore. Used to be on 30 mbps for $40/month.

Re: YouTube's road to HTTPS

#58

Post by azernik »

mdani wrote: post #39
acdha wrote: post #34

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…

It is very easy to implement this (I have worked on such a limiter before). You pick the point of entry into your network (wi-fi connection, ISP connection), keep packet and byte counts for every such point of entry, and limit them.

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.

Re: YouTube's road to HTTPS

#59

Post by foota »

mdani wrote: post #39
acdha wrote: post #34

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…

Really? T-Mobile should know your mac address and ip and be able to rate limit based on that.

Re: YouTube's road to HTTPS

#60

Post by azernik »

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.

That shaping should not be broken by HTTPS. The only things that would be affected by HTTPS is carriers munging the bits.
Post reply on HN