Re: [rtcweb] Requiring ICE for RTC calls

[Harald Alvestrand <[e-mail]>]

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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>