Subject: Re: [rtcweb] Efficient crypto for conferences

From: Harald Alvestrand <[email-masked]>
Date: Wed, 13 Aug 2014 15:36:59 +0200

Catching up on mail.....

On 07/23/2014 04:37 PM, Emil Ivov wrote:
> Hey all,
>
> Lately, we have been working on SFU-based conferencing. SFUs and 
> WebRTC go together quite well: SFUs scale beautifully and are very 
> latency friendly which makes them great for cloud deployment.
>
> But!
>
> There is a glass ceiling currently that I was hoping we could discuss.
>
> Performance.
>
> Currently the only way an SFU can operate is by terminating DTLS/SRTP 
> for every participant. This means decrypting and (worse) re-encrypting 
> all traffic that traverses the SFU. This easily accounts for 90% of 
> the CPU use on the SFU.

Do you have an actual measurement giving this figure? Over what 
configuration and AES implementation?

Last time I was evaluating this, I think profiling of the conferencing 
engine showed that less than 5% of the time was spent in the 
decrypt/encrypt functions - of course, we might just have been massively 
inefficient in the rest of the things that implementation was doing.

>
> This is not a difficult problem to solve and AVTCORE even has a WG 
> document that addresses it. It removes the need for decrypting and 
> allows SFUs to just forward packets.
>
> However, while chatting with many others in Toronto it appeared that 
> most of us are focused on solving a slightly different problem:
>
> Privacy.
>
> Or in other words: making it impossible (as opposed to unnecessary) 
> for SFUs to decrypt.
>
> While this is a notable effort, it is also much more complex and parts 
> of it (i.e. not requiring end users to trust their web provider) would 
> be arguably very hard to solve.
>
> Therefore, my question to the working group is: wouldn't it make sense 
> to try and solve the efficiency issue as a first step and then worry 
> about the privacy one on a later stage?
>
> Emil
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 13 Aug 2014 11:51:15 -0400

On Wed, Aug 13, 2014 at 9:36 AM, Harald Alvestrand <[email-masked]>
wrote:

>> Currently the only way an SFU can operate is by terminating DTLS/SRTP for
>> every participant. This means decrypting and (worse) re-encrypting all
>> traffic that traverses the SFU. This easily accounts for 90% of the CPU use
>> on the SFU.
>>
>

I think we are talking about different conferencing servers here. In case
of audio conferencing server where all the audio streams are received,
de-jittered, decoded, mixed, re-encoded, and then re-encrypted,
decryption/encryption procedures account for about 5-10% of the total CPU
load. In case of packet forwarding unit, where streams from one participant
is forwarded to several other participants as is (i.e, each conference
participant receives audio and video stream from each other participant and
then mixes audio on the client side and displays each video stream
independently), the forwarding unit receives packets from the network
decrypts/encrypts and forwards the data. A typical modern dual CPU Xeon
server can do about 1-2GB of traffic in cases where it needs to do
decryption/encryption and forward traffic. In cases where the server can
simply forward packets, it can easily do around 10GB of traffic. In other
words, encryption accounts for 90% of the CPU load on such server.
_____________
Roman Shpount