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

[Justin Uberti <[e-mail]>]

Note also that DTLS role can change during the lifetime of the session
(e.g. a peer that was active can become passive, and vice versa). So we
will need to be more specific about when the role is in fact determined -
perhaps the initial DTLS roles used in the session.


On Wed, Oct 30, 2013 at 1:49 PM, Ejzak, Richard P (Richard) <
[e-mail]> wrote:

> Hi Randell,
> Thanks again for your response.
>
> You asked what I thought would help to clear up any confusion around the
> stream id assignment issue.  I think clearer definitions of the different
> types of negotiation, and a few more guidelines in the text would be great.
>  Please correct any of the following suggested guidelines to avoid
> potential stream id conflicts.
>
> 1) For in-band negotiation before establishment of the SCTP association,
> the application should use only deferred stream id assignment based on DTLS
> role.  (A little discussion of what this means also wouldn't hurt.)
>  Otherwise a preselected stream id on one side might conflict with a
> deferred selection on the other side.
> 2) For external negotiation before establishment of the SCTP association,
> the application must select stream ids without waiting for determination of
> DTLS role.  Both peers need to know the stream id allocated to each data
> channel via the external negotiation mechanism, so deferred selection
> cannot be used.
> 3) Prior to establishment of the SCTP association, if the application has
> data channels to establish using both in-band and external negotiation,
> external negotiation data channels should always be created before in-band
> negotiation data channels.  This allows the protocol to avoid reusing any
> potentially conflicting stream ids allocated by the external negotiation
> mechanism.
> 4) After establishment of the SCTP association, in-band and external
> negotiation can be freely mixed as long as stream id assignment is based on
> DTLS role while avoiding already allocated ids.  For application selection
> of stream ids (rather than protocol selection of stream ids), the
> application can determine the DTLS role by examining the exchanged SDP
> messages.
>
> This paraphrases many of the things in your email that aren't yet in the
> draft.  Some of my confusion was that I was thinking of hybrid negotiation
> mechanisms to allow application selection of stream ids with in-band
> negotiation before establishment of the SCTP association, but it's far
> easier to simply disallow that!
>
> BR, Richard
>
> > -----Original Message-----
> > From: [e-mail] [mailto:[e-mail]] On
> > Behalf Of Randell Jesup
> > Sent: Tuesday, October 29, 2013 9:39 PM
> > To: [e-mail]
> > Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
> > 01.txt
> >
> > On 10/29/2013 11:06 AM, Ejzak, Richard P (Richard) wrote:
> > > 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.
> >
> > I'm definitely not ignoring it.  I'm not specifying what the
> > application does in the external negotiation; just how that affects the
> > protocol stacks at either end.  See my pseudo-code below, which has the
> > advantage of avoiding english vagueries.  I think part of the confusion
> > comes from looking/thinking about the JS API, not the IETF protocol.
> >
> > > 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.
> >
> > Agreed.
> >
> > > 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.
> >
> > Agreed.  That's how I've been using it, with what happens to decide on
> > what the two apps end up using to initialize the two ends being largely
> > out-of-scope to this discussion.
> >
> > > 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.
> >
> > No, I didn't mean that to be what the term meant.  Where do you think I
> > implied that?
> >
> > >    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.
> >
> > There are many ways the application can guarantee correct operation.
> > Letting the first side of an external negotiation request the stack
> > assign a free id of 'correct' oddness is merely an API helper at the JS
> > level; it has no impact on the protocol per se, and the application can
> > do it itself (with extra bookkeeping, as I stated).  As such, it's only
> > mentioned in the JS API spec, not the IETF drafts.
> >
> > > 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.
> >
> > This is the external negotiation - both sides tell the stack that a
> > channel has been agreed to.   "Agreed to" can be "one side send to the
> > other a channel definition, and the second side installs it, completing
> > the channel."  It also can be "both sides (same JS app) know a priori
> > that channel id 0 is the reliable control channel used for Foo
> > messages, and so inform the stack".
> >
> > > 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.
> >
> > I think the pseudo-code does cover it - as that's also virtually what
> > we've implemented (running code and all that). ;-)   The other
> > properties discussed emerge from that design and the JS API on top of
> > it.  You can see the actual (rather more messy!) code in
> > netwerk/sctp/datachannel/DataChannel.cpp in Firefox.  (Need to handle
> > failures, requirement to allocate more streams from SCTP, JS interface,
> > etc).
> >
> > Has my discussion above cleared up any of the confusion?  If it has, do
> > you have any proposed way to help others avoid that confusion?
> >
> > Thanks for looking at it before we're at the mics!
> >
> >      Randell
> >
> > >
> > > 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
> > > _______________________________________________
> > > 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
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>