W3C home > Mailing lists > Public > public-webrtc@w3.org > June 2012

Re: [ACTION-49] DataChannel issues

From: Randell Jesup <randell-ietf@jesup.org>
Date: Wed, 27 Jun 2012 12:09:51 -0400
Message-ID: <4FEB304F.3010606@jesup.org>
To: public-webrtc@w3.org
On 6/27/2012 5:00 AM, Stefan Hakansson LK wrote:
> On 06/27/2012 12:04 AM, Randell Jesup wrote:
>> On 6/26/2012 5:18 AM, Stefan Hakansson LK wrote:
>>> Adding a DataChannel object [ACTION-49]
>>>       Proposal written up by Randell
>>>       Not clear what the benefits of introducing it is
>> Options follow.  I prefer option #3 (with default channels in SDP, but
>> I'm also ok with them being held internally for creation on connection).
>> Note all of these assume the decision made in Stockholm, which was to
>> mirror the WebSockets API (channels must wait on onopen before you call
>> send()).
>> The connection object's main advantage is being able to ask it directly
>> for global stats, etc, instead of having those be methods on
>> PeerConnection - and if for any reason we want to enable DataChannels
>> via something other than PeerConnection, you'd have a discrete
>> object/interface already defined for it; or you could allow two data
>> connections (associations) per PeerConnection (though there are very
>> limited reasons I can see why).
>> I think "keep it simple, optimize only the common cases" is the right
>> tack.  Option #3, with the only optimization being to allow default
>> channels in the SDP because that's a very common case.
> I also like #3 best (or #4 - they do not seem that different to me).

The main difference is with #3 (w/SDP) you can pre-define the channels 
you want and avoid setup time after the PeerConnection gets connected. 
Many apps will just have a fixed set of data channels.  Downside is 
having to deal with the SDP side of things (more code, more complexity). 
  Martin Thompson wanted to find ways to optimize DataChannel creation, 
especially at call-start time.

Note that #3 does allow for the option of not using SDP, but queuing the 
creations inside PeerConnection.  This gives the user the nice API and 
is simpler, but also slower at startup.

> But a couple of questions:
> * Is there really a gain in adding "addDataChannel" and
> "closeAllDataChannels"? In the current draft [1] you can do "dc =
> pc.createDataChannel" and then dc.close. Would that not be sufficient?

It would, especially in case #3 (for #4, it would involve a mandatory 
renegotiation right after call start - a bad thing).

> For the very first data channel created there is an SDP o/a needed, but
> the app can treat that as opaque, just do the
> createOffer-setLocal-send... thing whenever a "renegotiationneeded"
> event is fired. And likewise, if all data channels have been closed a
> re-negotiation would be needed again, but this could happen as a result
> of the app closing all of them, no need for "closeAll".

Yes, those are all true, but especially the first would impact initial 
data channel creation time at call startup.  close/closeAll aren't 
mandatory at all, but they give you a 'hook' for dropping the 
association or keeping it warm (if you expect randomly arriving traffic, 
like if you use it to proxy other data - you don't want it autoclosing, 
so app developers would need to prop it open with a dummy connection).

> * I have never understood why there should just be a limited set of data
> channels signaled in the SDP o/a. If data is added, could not all SCTP
> streams be used? And if the app tries to open more than 64k (or whatever
> the limit is) there would be an error.

There's a delay to negotiate more streams (and in theory it can fail). 
We don't want to default to 65536 streams, because they do cost memory - 
not much, but there are tables in SCTP of streams.  The protocol will 
automatically add streams as needed; the suggested default is 16 

Randell Jesup
Received on Wednesday, 27 June 2012 16:10:23 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:28 UTC