Re: [rtcweb] Review request for RTCWeb standard signaling protocol

[Randell Jesup <[e-mail]>]

On 10/18/2011 7:40 PM, Ted Hardie wrote:
>
> On Tue, Oct 18, 2011 at 1:43 PM, Hadriel Kaplan <[e-mail]
> <mailto:[e-mail]>> wrote:
>     It *is* an advantage.  It puts the power in the hands of the app
>     developer, not the browser developer.
>
>
>
> As Peter Parker's uncle Ben tells, us, with great power comes great
> responsibility.  Yes, it gives them a choice, but it also makes them
> responsible for something that is, bluntly, infrastructure plumbing that
> most of them would rather just worked.

I'll come back to where I've been before - Give those who want it access 
to use their own signaling (on top of ROAP at the browser interface), 
and provide a "simple" default signaling mechanism that *can* be used on 
top of ROAP.

Responses to arguments against this:

1) Don't lock us in to a existing protocol because it blocks doing X

    This doesn't lock anyone in; all can use the ROAP interface directly
    and ignore this protocol offered by the browser.

2) If it's baked into the browsers, it will take years to update/bugfix

    A specific service (website/app) can replace the "standard" protocol
    with their updated implementation in JS any time they want - and
    could even serve it only to people running non-updated browsers.

3) It will take forever to design and agree to a new protocol

    A valid, good point.  That would point one to use an existing
    protocol, or a subset of one.

4) It bloats the browser with something no one will use

    I agree it will increase the browser size.  I would disagree that no
    one would use it.

I'll note that such a signaling library in the browser doesn't *have* to 
be required; a browser could offer it, and the service's app could use 
it if available and download a JS version if not.

This (and ROAP, and standard servers for the protocol) would allow the 
infamous "20-line" JS client, without tying anyone's hands.

>>     It's certainly less efficient and, given the majority of users now
>>     accessing the Internet via mobile devices which are power and
>>     bandwidth constrained, that sort of wastefulness should not be
>>     trivially dismissed.
>
>     If a mobile platform is so constrained of power and bandwidth that
>     downloading a JS library is difficult, it's unlikely it would be
>     able to handle RTP/RTCP media regardless.
>
>
> You don't get to be rich by making a lot of money, you get to be rich by
> keeping it.  The same is true with energy in mobile systems.  Pay
> attention to it all the time, and there's a fair chance you will never
> run out.  Pay attention to it only when you're low, and you're likely
> paying attention to late.

150KB signaling libraries can take time (and energy!) to download; if 
you only have the bandwidth for a narrowband audio call (and rtcweb is 
not just for video!) it could take up to 45 seconds worth of in-call 
bandwidth to download the signaling library alone.  Now, hopefully this 
is cached if it's a service you use a lot, but you can't count on it 
being cached in any particular instance.  Even if you have a 128K 
ISDN-equivalent connection, it's still around 10 seconds just to 
download the library.   Always remember, not everyone has megabit 
bandwidth, or a good wireless connection - and as Ted mentions, even 
those who do are often energy-constrained.  This is even more the case 
in developing countries that may be skipping a lot of the wired 
infrastructure we take for granted.

I'll also note that while browsers are very good at running JS code 
fast, it isn't always the most efficient way to go, and over time is 
less efficient due to repeated re-parsing and re-JIT-ing the same code. 
  A built-in-but-optional protocol would be more efficient both in usage 
(faster is also less energy spent) and in not requiring re-download and 
re-parse/re-JIT.  A major issue? probably not, but a valid consideration.


-- 
Randell Jesup
[e-mail]