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

Mark,

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

We read your announcement and paper with interest because we face similar questions about HTTPS termination of media streaming sessions. Summarising the figures presented in the results section of the paper:

* No TLS               ~19-20 Gbps
* OpenSSL          ~8.5 Gbps (~55 - 58 % dropoff)
* SSLsendfile     ~9 Gbps (~52 - 55% dropoff)

The difference between OpenSSL and SSLsendfile performance appears marginal, and still less than half the baseline performance. The authors comment that this improvement was not nearly as much as hoped. At any rate, this seems some way off the 30% clawback you were hoping for last October:

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

Since these numbers don't appear to provide significant improvement, can you explain what other factors have influenced the recent announcement on HTTPS support? The paper concludes by outlining some additional software improvements that could be made. How much closer to the original 20Gbps performance do you think these might bring you?

Lucas