Re: [rtcweb] Requiring ICE for RTC calls

Harald Alvestrand <harald@alvestrand.no> Fri, 30 September 2011 05:16 UTC

Return-Path: <harald@alvestrand.no>
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 DA2F221F8C87 for <rtcweb@ietfa.amsl.com>; Thu, 29 Sep 2011 22:16:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.497
X-Spam-Level:
X-Spam-Status: No, score=-109.497 tagged_above=-999 required=5 tests=[AWL=0.502, BAYES_00=-2.599, J_CHICKENPOX_52=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 uD6vggMsOCQI for <rtcweb@ietfa.amsl.com>; Thu, 29 Sep 2011 22:16:35 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id A7E1B21F8C73 for <rtcweb@ietf.org>; Thu, 29 Sep 2011 22:16:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 18F0439E0BB for <rtcweb@ietf.org>; Fri, 30 Sep 2011 07:19:27 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XaBpfxKj9Poh for <rtcweb@ietf.org>; Fri, 30 Sep 2011 07:19:26 +0200 (CEST)
Received: from [192.168.0.14] (c213-89-141-213.bredband.comhem.se [213.89.141.213]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 69B8339E098 for <rtcweb@ietf.org>; Fri, 30 Sep 2011 07:19:26 +0200 (CEST)
Message-ID: <4E85515E.5020102@alvestrand.no>
Date: Fri, 30 Sep 2011 07:19:26 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Thunderbird/3.1.13
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CAD5OKxtNjmWBz92bRuxka7e-BUpTPgVUvr3ahJGpmZ-U5nuPbQ@mail.gmail.com> <CAD6AjGSmz5T_F+SK2EoBQm6T-iRKp7dd4j8ZAF5JKdbbyomZQA@mail.gmail.com> <CALiegfmO54HC+g9L_DYn4jtXAAbLEvS++qxKa6TNrLDREs9SeA@mail.gmail.com> <4E80984A.903@skype.net> <CALiegfmyvTb57WVooKryS-ubfcg+w5gZ+zfO1zzBLn3609AzaA@mail.gmail.com> <4E809EE6.2050702@skype.net> <CAD5OKxvUOadaU0dnB7-Ho9cZ92VY+4Owuhj7oKPCx9Jy1iwT1Q@mail.gmail.com> <C2DF2C51-B3F7-443D-A047-7E6FB03E6D20@phonefromhere.com> <CAOJ7v-3AJJcdrCKcH4AJmv_016sZtcOPOo8yCv3Va65eJogAkQ@mail.gmail.com> <53C72381-DC23-4A6A-944C-B418791876B0@cisco.com> <CALiegf=nG+KXto9CXfn64CQSp3P5Lfm+S8c0xnA187Fhz=fcrQ@mail.gmail.com> <05B54E0C-B867-4D7F-825D-2E008E69B07F@acmepacket.com> <4E84F06B.7020705@skype.net> <2C381E05-59C5-4678-A431-CFDAC1098050@acmepacket.com> <CABcZeBMgFetriRkyvR_pOczWX6RCpMisjzjQeBsPYj9Zg3S0zQ@mail.gmail.com> <DF6B5635-BD84-4F87-9228-3EF3BBCC7129@acmepacket.com>
In-Reply-To: <DF6B5635-BD84-4F87-9228-3EF3BBCC7129@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] Requiring ICE for RTC calls
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: Fri, 30 Sep 2011 05:16:36 -0000

On 09/30/2011 06:37 AM, Hadriel Kaplan wrote:
> On Sep 29, 2011, at 10:37 PM, Eric Rescorla wrote:
>
>> Absent some measurements, I tend to agree with Matthew here.
>> My Macbook Air can do roughly 3x10^3 SHA-1 operations per
>> second on a single core. In order for this to be 10% of your load,
>> you would need to be processing on the order of
>> 75K STUN requests/sec/core. How many total calls/second
>> can you do/core w/o STUN?
> That's not the problem - the problem is "media" isn't handled in CPUs on many SBCs to begin with.  There're basically two types of SBC architectures in common use: software-based and hardware-based.  The software-based ones don't scale well in terms of concurrent call media capacity (for obvious reasons), so aren't usually used by service providers.  The hardware-based ones do media processing in dedicated hardware (ASICs, NPs, whatever).  To date, most hardware-based SBCs that I've seen couldn't possibly do SHA-1 for STUN messages in their base hardware without either additional hardware components (which costs more money), or they have to send the STUN messages back/forth to their signaling processors on an exception path, which means the overhead isn't just the SHA-1 alone.
Still, it's on the order of a few packets per call, and most hardware 
devices have a software processor for "exceptional processing" these 
days. What number of simultaneous calls per box are you envisioning?
>    So to be fair I shouldn't call it so much the overhead of SHA-1, as the overhead inflicted by going beyond what things like NPs can easily do by themselves (which is the SHA-1 piece).
>
> And this is in the context of the IPv4/v6 debate in MMUSIC, where any additional cost burden for service providers to bear to deploy IPv6 is a sunk cost with no additional revenue and thus very hard to support.  The RTCWeb model is a new "service" in some ways, so the market may bear a different cost burden for it.
>
> And I haven't been arguing against ICE for RTCWeb - I was a few weeks ago when I was hoping we could get away without it, but I don't see a safe way without it - I was only arguing in this thread against the notion of ICE-Lite being easy/free.
Time to change the subject line, then?
> The bigger problem is RTCP for G.711: since many SIP devices don't do RTCP, and there's no way to know if they do/don't from SIP signaling, having to have the SBC's create "fake" RTCP every 5 seconds for every call is a real ball-buster.
Let's use a different subject line for that one, too.
> -hadriel
> p.s. note, the above is based on what I know of 5 different SBC vendors' equipment - there are plenty more than that many SBC vendors in the World, but my assumption is they're not too dissimilar.
> p.p.s. some SBCs are "decomposed", meaning separate physical systems doing SIP signaling vs. media processing, and they're usually called things like "BGF" or "AGW" or whatever, but it's logically the same concepts.
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>