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

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

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

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.

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

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.

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