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

Hadriel Kaplan <HKaplan@acmepacket.com> Mon, 07 November 2011 15:42 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 314EF21F87D6 for <rtcweb@ietfa.amsl.com>; Mon, 7 Nov 2011 07:42:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.464
X-Spam-Level:
X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jLL6aWQfJ4b5 for <rtcweb@ietfa.amsl.com>; Mon, 7 Nov 2011 07:42:18 -0800 (PST)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 1001921F86D0 for <rtcweb@ietf.org>; Mon, 7 Nov 2011 07:42:17 -0800 (PST)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 7 Nov 2011 10:42:14 -0500
Received: from MAIL1.acmepacket.com ([169.254.1.232]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Mon, 7 Nov 2011 10:42:14 -0500
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Eric Rescorla <ekr@rtfm.com>
Thread-Topic: [rtcweb] Let's define the purpose of WebRTC
Thread-Index: AQHMnVQwkzEfyATo80e1sofLGuSnyQ==
Date: Mon, 7 Nov 2011 15:42:14 +0000
Message-ID: <F8003BA9-BCD8-4F02-B514-8B883FF90F91@acmepacket.com>
References: <CALiegfkVNVAs_MyU_-4koA4zRwSn1-FwLjY9g_oZVkhi9rSK5Q@mail.gmail.com> <8A61D801-D14D-408B-9875-63C37D0CC166@acmepacket.com> <CABw3bnPE=OY_h5bM7GA6wgrXiOBL8P4J0kw1jLv-GSpHAbg=Cg@mail.gmail.com> <CABcZeBNqdkh8u=gwOvKfDCQA7rXdAyQkfaM1r2Sx10787btP6A@mail.gmail.com> <B10FEFF6-0ADC-4DB1-83BB-50A11C65EC35@acmepacket.com> <CABcZeBNSXtim_VqzqAd8Z-u4zWSjaYmsVZPN=7sDYkJsgtRAHA@mail.gmail.com> <4EB7E6A5.70209@alvestrand.no>
In-Reply-To: <4EB7E6A5.70209@alvestrand.no>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <49CF0D086307B74C9A0B26AEEC82383B@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Let's define the purpose of WebRTC
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Nov 2011 15:42:19 -0000

On 11/07/2011 02:50 PM, Eric Rescorla wrote:
> On Sun, Nov 6, 2011 at 7:20 PM, Hadriel Kaplan<HKaplan@acmepacket.com>  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