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

[Paul Kyzivat <[e-mail]>]

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.
>
> I agree with this statement if the browser selection algorithm is based on DTLS role since the application needs to be able to select ids before the DTLS role is known.  It is also clear that this is not an easy problem to solve since the peers need to interact in some way before their relative roles are clearly established.
>
> I am ok with documenting this limitation clearly (i.e., that the application should use either browser selection of stream ids or application selection of stream ids but not both together) but have a suggested alternative solution for consideration.  I would prefer a solution where the two paradigms can be "mixed", if one can be agreed.
>
> 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.

	Thanks,
	Paul

> 	2. For early data channel creation, the browser assumes that it will take the offerer role in selecting stream ids until the application determines its role through the API (using JSEP API calls).
> 	3. The answerer application refrains from requesting browser selection of stream ids when creating data channels until after the browser knows it will take the answerer role (based on the sequence of JSEP API calls).  This is not a significant limitation since the answerer will typically not even create its end of the peer connection until after it receives the offer.
>
> This approach also has the advantage of being consistent with the data channel API spec as it is currently written, which requires stream id assignment at the time of data channel creation.
>
> Another (admittedly secondary) advantage of choosing a new selection algorithm that makes the two paradigms compatible would be that external negotiation options could use the same algorithm and also be fully compatible with the in-band options.
>
> BR, Richard
>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On
>> Behalf Of Harald Alvestrand
>> Sent: Thursday, October 24, 2013 11:30 PM
>> To: [e-mail]
>> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-data-protocol-
>> 01.txt
>>
>> On 10/24/2013 10:38 PM, Ejzak, Richard P (Richard) wrote:
>>> Hi Michael,
>>>
>>>> From: Michael Tuexen [mailto:[e-mail]]
>>>> Sent: Thursday, October 24, 2013 2:21 PM On Oct 24, 2013, at 8:36
>> PM,
>>>> "Ejzak, Richard P (Richard)"
>>>> <[e-mail]> wrote:
>>>>
>>>>> Justin, Michael,
>>>>> Thanks for the clarifications.  One more question.  What happens if
>>>> the application tries to select a stream id before the DTLS role is
>>>> known and it ends up selecting an invalid one?
>>>> I'm not completely familiar with the JS API, but if you want to
>>>> select a stream, aren't you managing the stream completely on your
>>>> own. I think the DTLS role stuff is only relevant if the streams are
>>>> managed by the browser.
>>> If this is the intent then that clarification would be very useful.
>> Reading the API text again, it is clear that the browser only manages
>> stream ids that it selects.  Does this mean that the browser stream id
>> selection option is not compatible with the application stream id
>> selection option?  Putting it more precisely, should we require that
>> the application not be allowed to select stream ids prior to
>> determining DTLS role if it expects that either side might use the
>> browser stream id selection option?  It would be easier if the even/odd
>> rule could be determined earlier than DTLS role establishment so that
>> the application could use the same even/odd assignment rule for early
>> data channel creation.
>>
>> My reading has been that once you start selecting IDs, you're
>> responsible for making sure those don't collide with platform-generated
>> ones, or deal with the result if they do.
>>
>> The result of
>>
>> A: pc.createDataChannel(label="foo") -> (channel with ID = 5, open
>> message sent)
>> B: pc.createDataChannel(label="bar", id=5) <open message arrives at B>
>>
>> should be well defined. I don't much care what the result is, as long
>> as it's well defined; closing the channel and calling the onerror()
>> handler with DOMError(error="UsageError", message="Duelling paradigms")
>> is fine with me.
>>
>> I can't see a way to mix the two paradigms that guarantees this never
>> happening.
>>
>>>
>>>>> Michael,
>>>>> While it's true that the data channel control protocol cannot open
>>>> the channel with the peer before the DTLS role is known, the API
>>>> allows the application to create the data channel before the DTLS
>>>> role is known, in which case the sending of the Open message must
>>>> wait until the SCTP association is established.  I want to know what
>>>> the application is supposed to do it if needs to create data
>> channels
>>>> with preselected stream ids before the DTLS role is known.  This
>>>> seems like something that the spec should make clear rather than
>>>> leaving it to implementation.
>>>> Can you assign the stream ID in the API? Could you point me to the
>>>> text?
>>> http://www.w3.org/TR/webrtc/#methods-1 describes the "id" attribute
>> in the RTCDataChannelInit dictionary that must be the equivalent of the
>> "stream identifier".  No other interpretation makes sense to me but
>> please correct me if I am wrong.  Note in particular the following text
>> within the description of the createDataChannel procedure (my
>> parenthetical): "If the value of the id attribute is null, initialize
>> it to a value generated by the user agent (browser), according to the
>> WebRTC DataChannel Protocol specification, and skip to the next step.
>> Otherwise, if the value of the id attribute is taken by an existing
>> RTCDataChannel, throw a TBD exception and abort these steps."  So "id"
>> must refer to "stream identifier" since there is no other id in your
>> draft that it could refer to.
>>>
>>> If I'm right, then it would be good if it were made clear that id
>> refers to "stream identifier", but that is a w3c issue.  Quoting from
>> 5.2.1 (my parentheticals for clarity): "The id was either assigned by
>> the user agent (browser) at channel creation time (not channel opening
>> time) or selected by the script (application). The attribute MUST
>> return the value to which it was set when the RTCDataChannel was
>> created (not opened)."
>>>
>>> I used the wrong terminology in my earlier mail when I referred to
>> "open" of the data channel when I meant "creation".  Since the data
>> channel can be "created" before DTLS role is known and before the data
>> channel can be opened, the quoted text above would seem to indicate
>> that the application can never determine the stream id actually
>> assigned to the data channel if id can't be determined at time of
>> creation.  Justin implied that the chrome behavior does not conform to
>> this description.  Comment, Justin?
>>>
>>> It still seems to me that a change in the rule describing even/odd
>> stream id assignment would be a good idea.
>>>
>>> BR, Richard
>>> _______________________________________________
>>> rtcweb mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>