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

[Tim Panton <[e-mail]>]

On 19 Oct 2011, at 08:43, Randell Jesup wrote:

> 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.

True - but those are _exactly_ the environments which _won't_ need all the second order requirements of detailed management of video codecs 
and multiple streams (i.e. the ones that make us 'need' SDP). They will run a single codec (amr-nb presumably) and not negotiate. The signalling 
library for that could be _incredibly_ simple, small and efficient, provided that they don't have to implement a full legacy protocol and can delegate
the hard work to a solar powered webserver elsewhere. 
  
(As an aside, why would you use a PSTN-alike-web app on a GSM phone if you were worried about battery life? 
GSM's power management is going to trounce anything we can do on the VoIP side for some years. 
So this use case requires the _tightest_ possible web integration to justify it)

As a datapoint, phono's xmpp/jingle implementation (including support for 4 different audio backends) is < 100k , It does IM and audio with multiple codecs. I doubt that adding video would tip it over the 100k mark. But that is a full legacy protocol. 
Setting up a basic audio call should be the proverbial 20 lines of javascript - if one uses Neil's low-levelAPI proposal.

> 
> 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.

Sure, but you have to weigh that benefit against the downsides of picking the _wrong_ protocol. (which I've already ranted about at length)

I take the point that this is an 'built-in-but-optional protocol' - 
but worry about the slippery slope from 'optional' to 'default' to 'only-supported-way' to 'standard' .
How do you propose to  prevent that natural and inevitable progression taking place 
(probably before the first browser ships with it in) ?



> 
> 
> -- 
> Randell Jesup
> [e-mail]
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb