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

Serving Netflix Video Traffic at 400Gb/S and Beyond (2022) [pdf]

nabstreamingsummit.com

Post reply on HN
Print view View original

1–10 of 22 posts

Re: Serving Netflix Video Traffic at 400Gb/S and Beyond (2022) [pdf]

#3

Post by monocasa »

comment0r wrote: post #2

Assuming the files are encrypted anyway for DRM reasons: why should static content like movies be TLSed? I know I know, "TLS all the things", but it sounds like a high cost at Netflix scale.

It seems like it took engineering work, but TLS isn't their bottleneck when the data flow is structured correctly for the hardware (which is kind of the thesis of a lot of the Netflix CDN node optimization stuff).

Re: Serving Netflix Video Traffic at 400Gb/S and Beyond (2022) [pdf]

#4

Post by xxpor »

comment0r wrote: post #2

Assuming the files are encrypted anyway for DRM reasons: why should static content like movies be TLSed? I know I know, "TLS all the things", but it sounds like a high cost at Netflix scale.

Stops Comcast from seeing the metadata and knowing exactly what their mutual customers are streaming.

Re: Serving Netflix Video Traffic at 400Gb/S and Beyond (2022) [pdf]

#6

Post by booi »

xxpor wrote: post #4
comment0r wrote: post #2

Assuming the files are encrypted anyway for DRM reasons: why should static content like movies be TLSed? I know I know, "TLS all the things", but it sounds like a high cost at Netflix scale.

Stops Comcast from seeing the metadata and knowing exactly what their mutual customers are streaming.

wait till you hear about what smart tvs do..

Re: Serving Netflix Video Traffic at 400Gb/S and Beyond (2022) [pdf]

#7

Post by keane »

comment0r wrote: post #2

Assuming the files are encrypted anyway for DRM reasons: why should static content like movies be TLSed? I know I know, "TLS all the things", but it sounds like a high cost at Netflix scale.

I would have thought this would have originally been driven by wanting to prevent a browser mixed content warning given that something like 15% of Netflix viewing happens in browsers (and the browser warnings switched to blocking in 2020 [Chromium] and 2024 [WebKit/Gecko]).

@drewg123 starts discussing this section at 4:21 in the presentation: https://www.youtube.com/watch?v=WzfADu1qyAM&t=261 ("we had this mandate that we had to start encrypting communications between our servers and our clients")

Netflix announced the change in 2016, citing viewer privacy from eavesdropping: https://netflixtechblog.com/protecting-netflix-viewing-priva...

However, I wonder if the mandate was led by Apple. It looks like it was 2015 (at iOS 9.0 / macOS 10.11) that Apple began requiring that network connections made by apps use TLS. While exceptions are allowed, they are discouraged and require a justification for App Store review: https://developer.apple.com/documentation/security/preventin...

Re: Serving Netflix Video Traffic at 400Gb/S and Beyond (2022) [pdf]

#8

Post by the-smug-one »

booi wrote: post #6
xxpor wrote: post #4

Earlier quoted context omitted.

Stops Comcast from seeing the metadata and knowing exactly what their mutual customers are streaming.

wait till you hear about what smart tvs do..

I refused to connect my TV to the internet and use a Vero V for all of my watching needs. The Vero V is absolutely worse than most other experiences, but I'm happy.

Re: Serving Netflix Video Traffic at 400Gb/S and Beyond (2022) [pdf]

#9

Post by shanemhansen »

Just an interesting observation I had about this once when I noticed that kernel quic implementations weren't very fast.

KTLS is mostly useful if paired with sendfile (I'm ignoring io_uring because I'm not as up to date on that). Otherwise you have to context switch back to userspace constantly.

Re: Serving Netflix Video Traffic at 400Gb/S and Beyond (2022) [pdf]

#10

Post by epistasis »

This probably has a very simple answer, but I always wonder how the provide load on these sorts of tests. Can you get by with 2-4 other servers with 400Gb/s links and just tons and tons of simulated IPs/ports to activate LACP balancing? Because you probably want to simulate simultaneous clients that stream at varying rates, probably in the range of 0.3 - 10 Mbps, which means hundreds of thousands of clients to saturate at 800 Gbps, right?
Post reply on HN