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

["Ejzak, Richard P (Richard)" <[e-mail]>]

Hi Randell,
There is clearly a problem with terminology here that is not allowing us to converge.  Even after your explanation, I believe my issues/questions remain valid.  I understand that we are discussing the data protocol draft, but we cannot ignore the pure external negotiation case when discussing compatibility issues.

When I refer to in-band negotiation, I mean the use of the data channel protocol Open message to inform the peer browser that a specific stream id has been allocated to a data channel.

When I refer to external negotiation, I mean the case where the data channel protocol Open message is NOT used but instead both applications need to use the create data channel method on the API to each browser to create both ends of each data channel.

You apparently also use the term "external negotiation" to apply to the case where in-band negotiation needs to be augmented with additional communication (i.e., in addition to the Open message) between the applications.  I consider this just a special case of in-band negotiation.  Clear terminology to separate these cases would be useful since they have very different characteristics.  Perhaps "augmented in-band negotiation" or "hybrid in-band/external negotiation"?

The application can choose when creating a data channel via the API whether to select the stream id for the data channel or to request the browser to select the stream id.  Apparently there are cases when the application MUST use only one of these options to guarantee correct operation.

The application can also specifically request whether to send the data channel Open message once the SCTP association is established.  It is understood that if the browser does not send the Open message that the peer application must also use its API to create the other end of the data channel.

Without going through all the cases again, I think it's fair to say that the situation warrants some additional explanation (in the drafts) to describe these various cases and under what circumstances each is allowed.  Your pseudo-code does not cover all the cases, and the situation is more subtle than you describe it to be.  The current drafts are far from adequate in this regard.

Please just answer one question: How does the application determine its DTLS role (i.e., whether to request even or odd numbers when choosing to select stream ids)?  Does this need to be inferred from allocated stream ids or can the application determine it directly?

Thanks,
Richard
 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On
> Behalf Of Randell Jesup
> Sent: Monday, October 28, 2013 11:45 PM
> To: [e-mail]
> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
> 01.txt
> 
> 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
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb