Re: [rtcweb] Let's define the purpose of WebRTC

[Hadriel Kaplan <[e-mail]>]

On 11/07/2011 02:50 PM, Eric Rescorla wrote:
> On Sun, Nov 6, 2011 at 7:20 PM, Hadriel Kaplan<[e-mail]>  wrote:
>> Who said "too slow"?  There *is* an extra round-trip or two involved I presume, if we're talking DTLS-SRTP, but no I didn't mean that as a "hit".  I just meant the extra computing cycles for SRTP being a "hit".  For WebRTC-to-WebRTC I don't think that matters at all.  For WebRTC-to-media-server it might, for a free game app or greeting card app that don't care about it to begin with, and which use plaintext HTTP to begin with.
> Sorry, I didn't mean to put words in your mouth. Performance measurements
> of HTTP versus HTTPS in modern Web environments suggest that the additional
> load for HTTPS is not significant. Do you have evidence that the situation is
> different for SRTP versus RTP?

Only from the DSP guys, and those would be hardware DSPs not softDSPs.  It runs them anywhere from 10-25% overhead, they say, depending on the vendor and what else their DSPs are doing at the time.

But ultimately even in software I assume it's all relative to what other work you're doing.  If you have to render a video stream on a screen and encode camera input into a codec being sent out, then my guess is SRTP overhead is a tiny factor not worth talking about.  If you're mixing multiple RTP streams as a conference server, then I assume doing SRTP for thousands of simultaneous audio RTP streams for multiple simultaneous conferences becomes noticeable.  Or at least so they seem to claim - I don't know since I don't build a media server (hardware SBCs often offload SRTP onto dedicated hardware).  One large software company even created their own proprietary packet format for SRTP that they claimed was done for improving performance/scalability, so I assume it has some impact they don't want their customers to incur.

-hadriel