It's funny to think that pushing 196gbps is possibly just as little as ~8000 simultaneous streams.

Also a shame that it is TLS'd. The content already has its own DRM/encryption.

TLS plays a different role. It makes sure you're receiving the Netflix's DRMed and encrypted content, and not some MITMed content that also happens to be correctly DRMed and encrypted, but contains something else.

Easy enough to make the content authenticate itself, instead of repeating cryptographic work for each viewer.

E.g. every 64k block contains a SHA256 hash of the next 64k block. When a user seeks, you provide the hash of the first block they'll be receiving over a trusted channel. (It already can exist at start of stream RSA signed or whatever).

But that's probably a pain when you have so many different devices to support.

(It also makes it harder to figure out what content people are watching... Though I think they use variable bitrate encoding which will fall to traffic analysis).

This exists in a more advanced form already

https://wicg.github.io/webpackage/draft-yasskin-http-origin-...

No... it's not the same as signed HTTP exchanges, which you'd generally use inside TLS, and involves signing all of the data in an exchange. It wouldn't work very well for streaming, either.

The important feature of the scheme that I mentioned is that there's no per-client encryption needed, except maybe a small operation on each client seek in the stream. In general, you just serve the file, and the file contents are self-authenticating against tampering.

You might use signed HTTP exchanges to push the first hash in the chain on a seek, I guess. Or just run it over TLS. Or just have a 64k block pre-signed at the beginning stream with the hashes of 2k chosen seek points that the client can store.

TLS keeps your viewing history private from third parties (e.g. your ISP).

What’s the problem with TLS? The performance overhead of it is minimal these days.

It depends on the application; but for bulk transit of already encrypted (presumably by DRM) data, it is a significant overhead for little value.

You can go back and look at Netflix presentations from when they switched to TLS, and they were no longer able to saturate their network cards (and here, they're at 50% on network still)

Yes, but the parent was talking sharing the competitive advantage of the patch.

But (a) what other streaming services even have CDN appliances, and (b) of the ones that do, which are using FreeBSD as a base?

If none of Netflix's competitors will use this patch, then it makes no material difference whether they share it or not.

A) at least FB and Google, probably Amazon too, plus you know, lots of CDNs have CDN appliances.

B) as far as I'm aware, everyone else is running Linux, except maybe one of the CDNs, but I don't know if that CDN is actually running appliances.

However, everyone and their uncle are launching a streaming service in the next 18 months, some of those might get enough traffic to justify appliances, and they can take Netflix's work here to get a competitive box off the bat.

Also, at any point, one of the current big guys can say "hey, netflix gets 200gbps from one box, why do we have 4? Why don't we try FreeBSD on some of these"

CDN appliances are pretty isolated, so it doesn't matter as much if most of their proprietary stack isn't ported. Chances are, they've got someone on staff with FreeBSD experience, and FreeBSD experience ages better, because there's less churn.

I would say that has less to do with Netflix and more the recent generation of Intel/EPYC server computing. These numbers seem pretty standard for this generation of Skylake/Cascade Lake and one NIC per NUMA also feels pretty standard to me. The patches also seem to be the usual problem when you are starting to care about NUMA, where there are a couple places where it just wasn't added but you need it.