Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-01.txt

[Randell Jesup <[e-mail]>]

On 10/28/2013 9:22 PM, Ejzak, Richard P (Richard) wrote:
> Hi Randell,
> Thanks for suggesting the stream id assignment algorithm below.  Please bear with me a little longer.  I agree that limited coexistence of application and browser stream id selection is possible, but it seems that there are some significant restrictions.
>
> Using in-band negotiation, I cannot see any way in which application selection and browser selection of stream ids can co-exist before DTLS roles are determined.  If application A selects an odd stream id, the only way to communicate this selection to application B's browser is via the in-band open message after the SCTP association has been established.

No, the application can tell the other end that in conjunction with the 
offer (i.e. in application-specific signaling that accompanies the 
offer).  Any application using external negotiation must, in fact, 
handle external negotiation (even if that 'negotiation' is a set of 
hard-coded channel ids).

Any later non-external-negotiated channel creations will select an 
unused id of the correct even/oddness (per DTLS role).  One SHOULD 
create all initial-connection-time externally negotiated channels before 
adding any new automatic (data-protocol) ones, in order to avoid 
surprises -- though I'd be rather surprised that an application would 
mix them in that way.  If the app does, it will work fine though.

There is an implicit assumption that anything using external negotiation 
is either two instances of the same JS app or a cooperating app and 
server (those are by far the most common cases, and virtually the only 
cases), or two different apps that nonetheless know how to talk to each 
other and negotiate the channels on their own (I'll believe this when I 
see it, but it might happen).  External negotiation was added 
specifically for these pre-cooperating cases.

Also, one point perhaps missed from the W3 spec:

    7. If the value of the |id
    <http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-datachannel-id>|
    attribute is null, initialize it to a value generated by the user
    agent, according to the WebRTC DataChannel Protocol specification,
    and skip to the next step. Otherwise, if the value of the |id
    <http://dev.w3.org/2011/webrtc/editor/webrtc.html#dom-datachannel-id>|
    attribute is taken by an existing ||RTCDataChannel|
    <http://dev.w3.org/2011/webrtc/editor/webrtc.html#idl-def-RTCDataChannel>|,
    throw a |TBD| exception and abort these steps.

Note this means you can create a channel for external negotation and let 
the browser select the id (which you then would tell the other side, and 
*they* would specify it to their end).  Note that the ID will not be set 
until DTLS roles are decided (and that's when onopen should fire as 
well).  This would not be very useful for setting up channels before 
offer/answer, but once offer/answer has completed, it lets you get a 
local channel id of correct oddness without having to scan all current 
datachannels to find an unused id value (assuming you're mixing styles 
of creation).

(We may need to add a line to the IETF drafts to cover this case; need 
to check).  The application *could* just scan all known channels 
instead, that's just a pain.  And it really only matters if you mix 
types, which is likely to be rare outside of "create these N hard-coded 
channels at offer/answer time, then have some dynamic 
(automatically-assigned-id) channels that get used later if needed."

>    It doesn't help to tell application B since it can't report the information to its browser.  So if application B creates another data channel and requests browser selection of a stream id then B's browser might end up selecting the same odd stream id, since it has no way to know to avoid it.  Not unless we reserve id values exclusively for application selection.  Do you agree?  If so, we should document this restriction.

When you tell the browser/protocol that a channel has been externally 
negotiated, it will mark that as in-use of course. That's why collisions 
can only happen when the other side creates an externally-negotiated 
channel of the "wrong" oddness in a race with an automatic creation from 
this side.  This is trivially avoided when building an app.

Much of this  discussion in the mail I'm replying to is moot, since it's 
based on an incorrect assumption about mixing.

> There is no problem if only browser selection of stream ids is allowed before the SCTP association is established since both applications can learn which side owns odd/even values after channel open is reported to the peer (since there has to be at least one data channel created to trigger the establishment of the SCTP association).  Now application and browser stream id selection can co-exist without a hitch.
>
> If we assume only application selection of stream ids is allowed with in-band negotiation before the SCTP association is established, then we can also allow co-existence of application selection and browser selection of stream ids after establishment of the SCTP association, as long as there is a way for each application to determine DTLS role.  They can't use the trick in the last paragraph since the browsers haven't been asked to assign any stream ids.  Is there an API mechanism available to determine DTLS role?  Am I missing something here?
>
> With external negotiation, only application selection of stream ids can be allowed before DTLS role is determined since the external negotiation mechanism needs to be able to report to both peers (and browsers) the stream id(s) selected.  Once DTLS role is determined then application and browser selection of stream ids could co-exist, but requires that the applications learn which DTLS roles were negotiated (same issue as above).
>
> Interestingly, in-band and external negotiation can co-exist before DTLS role is established as long as application selection of stream ids is used exclusively.  All forms of in-band and external negotiation can co-exist after the SCTP association is established as long as the applications know the DTLS roles.

I'm not going to reply line-by-line here, since I think much of this is 
based on a slightly incorrect understanding.

> In summary, the following combinations are allowed:
>
> 1) application selection with in-band negotiation before SCTP established and app determines DTLS role
> 2) browser selection with in-band negotiation before SCTP established
> 3) application selection with external negotiation before app determines DTLS role
> 4) application selection with in-band and external negotiation before SCTP established and app determines DTLS role
> 5) any combination of selection and negotiation after SCTP is established if DTLS role is available to app

I'd put it this way:

1)  You can create any number of DataChannels before 
createOffer()/createAnswer() so long as all of them are automatically 
assigned ids (what you call browser selection).  The actual ids are 
assigned after the DTLS roles are known.

2)  You can create any number of externally-negotiated channels before 
createOffer().  There is no need for them to match DTLS roles.

3) The answerer must create any externally-negotiated channels from its 
side before the channels can be used, and also SHOULD do so before 
creating automatic channels unless the application has made sure somehow 
a collision is impossible/unlikely.   In reality, there's no reason not 
to install the externally-negotiated channels before trying to create 
more, so the point is basically moot. (Note: you don't have to install 
the externally-negotiated channels before createAnswer, though normally 
I'd suggest doing so, just before creating automatically-generated ones.)

4) You can create externally-negotiated channels and then automatically 
negotiated channels before calling createOffer.  You can even mix them, 
since the automatically-generated ones will be assigned ids later when 
DTLS role is known (and will avoid any already in-use).  I'm not sure 
this is behavior that anyone would *need*, so I see no reason to promote 
mixing in that way - but it'll work.

5) Once the association is up, the application can use the method above 
(negotiated=true but no id=N) to allocate ids without fear of collision 
with automatic channels.

This is all emergent from the even/odd selection and letting the 
protocol choose ids when not externally negotiated.

Pseudo-code:

creation:
     externally-selected-id?
         yes-> mark channel in use
             if channel already in use complain and fail
         no-> dtls role known?
             yes-> assign unused channel of correct oddness; send OPEN
             no-> queue channel id selection
     fire onopen if association is up

incoming OPEN message:
    if channel already in use
       yes-> complain (perhaps fire onerror TBD)
       no-> Mark channel in use; inform application (ondatachannel); 
send ACK

Pretty darn simple.

>
> If DTLS exchange and SCTP establishment are associated with separate offer/answer transactions, there might be a few more combinations to consider.  The list also does not describe what is possible if DTLS role is not available directly to the apps.

DTLS and SCTP association establishment are async to offer/answer 
(kicked off by successful offer/answer completion).

>
> The above discussion might be an argument for segregating the stream ids available for application and browser selection.  There sure are plenty of them.  What do you think?  Then we wouldn't need to make DTLS role available to the app and there would only be a few restrictions on browser selection (it can't be used for external negotiation before DTLS role is determined).  And you could always have an overflow rule.
>
> Please correct me if I have missed anything.  Thanks!
>
> BR, Richard
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Randell Jesup
>> Sent: Sunday, October 27, 2013 4:46 AM
>> To: [e-mail]
>> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
>> 01.txt
>>
>> On 10/26/2013 6:30 PM, Paul Kyzivat wrote:
>>> Richard,
>>>
>>> On 10/25/13 4:51 PM, Ejzak, Richard P (Richard) wrote:
>>>> Hi Harald,
>>>> You said: " I can't see a way to mix the two paradigms that
>>>> guarantees this never happening."  The two paradigms being browser
>>>> selection vs. application selection of data channel stream ids.
>> You can.  You just have to be careful.  For example, your application
>> could define that pre-negotiated channels will use 100-110, and then
>> specify those to both ends before association/offer/answer.  Later it
>> could use data-protocol to add dynamic channels (using even-odd).
>> Since we've told both ends about 100-110, there's no problem here.
>> Even/odd is ONLY to avoid glare when both sides decide to open a
>> channel "at the same time".  If you add a pre-negotiated channel after
>> initial establishment, it's up to you to avoid colliding with any
>> existing channels and to avoid colliding with any in-process-of-
>> creation dynamic
>> (data-protocol) channels.  There are a number of ways to avoid such a
>> collision safely (never use dynamic channels; use the DTLS role or an
>> existing dynamic channel id to determine even/odd, etc).
>>
>>>> My proposal has three elements, which together can guarantee that
>>>> there are no stream id allocation conflicts between peers:
>>>>      1. The browser and application select stream ids based on
>> initial
>>>> SDP offerer/answerer role rather than DTLS role (e.g., initial
>>>> offerer uses even ids, initial answerer uses odd ids). With this
>>>> rule, the offering application knows its role immediately without
>>>> waiting for the DTLS or SDP handshake to occur.
>>> A similar issue has come up in the discussion of partial
>>> offers/answers. (Regarding how to assign a=mid values.) And a similar
>>> solution was proposed.
>>>
>>> It was then rejected on the basis that sometimes both "ends" think
>>> they are offerers or answerers. This comes about as a result of
>>> signaling-only B2BUAs that play games with O/A on two legs.
>> Exactly why we went with DTLS roles.
>>
>> --
>> Randell Jesup -- rjesup a t mozilla d o t com
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Randell Jesup -- rjesup a t mozilla d o t com