Re: [EME] HTTPS performance experiments for large scale content distribution

All,

Around 6 months ago, I reported on Netflix's experimentation with HTTPS
with our existing server infrastructure and the up to 50% capacity hit we
had observed, driven by our traffic mix.

At that time, we were uncertain of the gains we could achieve with software
and hardware optimization and of the timescale for those. I'm pleased to
report we have made good progress on that and we presented our FreeBSD work
at the Asia BSD conference [1][2].  We now believe we can deploy HTTPS at a
cost that, whilst significant, is well justified by the privacy returns for
our users.

So, as we mention today in our investor letter, we intend to roll out HTTPS
support over the coming year - for both our site and the content itself -
starting with desktop browser tests at scale this quarter.

It remains a concern, though, that restricting EME to secure origins will
reduce the incentive to ensure privacy and security issues are fully
addressed in the CDM itself, for example by ensuring all distinctive
identifiers are origin-specific, encrypted and user-clearable.

...Mark

[1] https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf
[2] https://2015.asiabsdcon.org/timetable.html.en#P7A



On Fri, Oct 24, 2014 at 11:00 AM, Mark Watson <watsonm@netflix.com> wrote:

> All,
>
> We have done some testing
> ​on the Netflix CDN ​
> with HTTPS
> ​. We dedicated several servers to serving only HTTPS traffic and directed
> traffic from our Silverlight clients to those servers in order to measure
> the serving capacity, as compared with similarly situated servers serving
> over HTTP.
>
> We​
> discovered that with our existing hardware/software stack
> ​[1] ​
> we would incur a capacity hit of between 30-53%
> ​ using HTTPS​
> depending on the server hardware/software version. This is due in part to
> the computational overhead of encryption itself (despite use of Intel hw
> acceleration) and in part to the unavailability of optimizations that, with
> HTTP, can avoid data copies to/from user space. This is not a capacity hit
> we
> ​c
> ould absorb in the short term and we estimate the costs over time would be
> in the $10’s to $100’s of millions per year.
>
> Our current rough estimates indicate that, over the coming year we could
> implement additional software optimizations which could potentially reduce
> ​the size of this
>  overhead
> ​by around​
>  30%
> ​
> and with modified hardware (over the next several years)
> ​by around
>  70-80%.
> ​We have not decided to do this, it's just an illustration of technical
> feasibility.
>
> ​I think it's unreasonable to expect that standards action alone can be
> successful in the face of such costs​. What is needed is a collaborative
> discussion to work towards solutions and on timeframes that are not
> cost-prohibitive.
>
> ...Mark
>
> PS: For the avoidance of any doubt, I am talking here only about delivery
> of content that is already encrypted at rest on the server. We have many
> mechanisms in place, including HTTPS, to protect sensitive user data such
> as account details, credit card information etc.
>
> [1] See https://www.netflix.com/openconnect for an overview, although
> this does not cover more recent designs
>
>
>