Subject: Re: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel

From: Christian Groves <[email-masked]>
Date: Wed, 12 Nov 2014 14:17:42 +1100

Hello

I had a chance to look over the latest draft in more details. Some 
comments/questions:

5.1.1.1: To enforce the text about dcmap-opt the ABNF could be updated:
    dcmap-opt       = ordering-opt / subprotocol-opt / label-opt
                      / ( maxretr-opt / maxtime-opt )

5.1.1.3: I think you can remove the "action item". 
draft-ietf-rtcweb-data-protocol indicates "The protocol field is to ease 
cross-application interoperation("federation") by identifying the user 
data being passed with an IANA-registered string ('WebSocket Subprotocol 
Name Registry' defined in [RFC6455]). I wouldn't see the out of band 
method using a different registry.

5.1.1.4. max-retr parameter: This draft seems to use the absence of the 
"max-retr" parameter to indicate the use of a reliable channel It also 
indicates a default value of "unbounded". 
draft-ietf-rtcweb-data-protocol indicates "For reliable Data Channels 
this field MUST be set to 0 on the sending side and MUST be ignored on 
the receiving side."
To better align with the data channel protocol i'd suggest changing the 
of 5.1.1.4 to indicate that "The max-retr parameter is optional with the 
default value equal to 0 indicating that no retramsmission is used.

Also is the term "unreliable" appropriate given that the data channel 
protocol talks about "partial reliability"?

5.1.1.5 similar to 5.1.1.4 I think it would be better to talk about 
specific behaviour when the parameter is omitted rather than saying 
"unbounded".

6. Example: In the examples a=dcmap:0 subprotocol="BFCP";label="BGCP" 
lines. Is the B<G>CP for the label intentional?

Regards, Christian

On 28/10/2014 1:39 AM, DRAGE, Keith (Keith) wrote:
> Based on the discussion on list over the last few days, I have submitted revised versions of the two SDP negotiation over data channel drafts as follows:
>
> A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt
> has been successfully submitted by Keith Drage and posted to the IETF repository.
>
> Name:		draft-ejzak-mmusic-data-channel-sdpneg
> Revision:	02
> Title:		SDP-based "SCTP over DTLS" data channel negotiation
> Document date:	2014-10-27
> Group:		Individual Submission
> Pages:		22
> URL:            http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-channel-sdpneg-02.txt
> Status:         https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-channel-sdpneg/
> Htmlized:       http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-02
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-data-channel-sdpneg-02
>
> Abstract:
>     The Real-Time Communication in WEB-browsers (RTCWeb) working group is
>     charged to provide protocols to support direct interactive rich
>     communications using audio, video, and data between two peers' web-
>     browsers.  For the support of data communication, the RTCWeb working
>     group has in particular defined the concept of bi-directional data
>     channels over SCTP, where each data channel might be used to
>     transport other protocols, called sub-protocols.  Data channel setup
>     can be done using either the internal in-band band (also referred to
>     as 'internal' for the rest of the document) WebRTC Data Channel
>     Establishment Protocol or some external out-of-band simply referred
>     to as 'external negotiation' in the rest of the document . This
>     document specifies how the SDP offer/answer exchange can be used to
>     achieve such an external negotiation.  Even though data channels are
>     designed for RTCWeb use initially they may be used by other protocols
>     like, but not limited to, the CLUE protocol.  This document is
>     intended to be used wherever data channels are used.
>
>
> A new version of I-D, draft-ejzak-mmusic-msrp-usage-data-channel-01.txt
> has been successfully submitted by Keith Drage and posted to the IETF repository.
>
> Name:		draft-ejzak-mmusic-msrp-usage-data-channel
> Revision:	01
> Title:		MSRP over SCTP/DTLS data channels
> Document date:	2014-10-27
> Group:		Individual Submission
> Pages:		11
> URL:            http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-usage-data-channel-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage-data-channel/
> Htmlized:       http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data-channel-01
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-msrp-usage-data-channel-01
>
> Abstract:
>     This document specifies how the Message Session Relay Protocol (MSRP)
>     can be instantiated as a data channel sub-protocol, using the the SDP
>     offer/answer exchange-based external negotiation defined in
>     [I-D.ejzak-mmusic-data-channel-sdpneg].  Two network configurations
>     are documented: a WebRTC end-to-end configuration (connecting two
>     MSRP over data channel endpoints), and a gateway configuration
>     (connecting an MSRP over data channel endpoint with an MSRP over TCP
>     endpoint).
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Wed, 12 Nov 2014 20:09:00 +0100

Hello Christian,

Thank you for your comments.
Please see my remarks inserted below.

Thanks,
Juergen

On 12.11.2014 04:17, Christian Groves wrote:
> Hello
>
> I had a chance to look over the latest draft in more details. Some comments/questions:
>

[Juergen] Actually, I am not sure if this would formally prevent maxretr-opt and maxtime-opt  from 
both being present simultaneously, as we would still have
     dcmap-value = dcmap-stream-id [ SP dcmap-opt *(";" dcmap-opt) ]
(allowing an arbitrary number of "dcmap-opt").
My understanding of RFC 5234's definition of "alternation" has so far been that
      dcmap-opt = ordering-opt / subprotocol-opt / label-opt / maxretr-opt / maxtime-opt
and
     dcmap-opt = ordering-opt / subprotocol-opt / label-opt / ( maxretr-opt / maxtime-opt )
are actually equivalent.
Right now don't see a "compact" way of strengthening the actual ABNF rules without having to list 
all possible parameter combinations and permutations.

>
>
> 5.1.1.3: I think you can remove the "action item". draft-ietf-rtcweb-data-protocol indicates "The 
> protocol field is to ease cross-application interoperation("federation") by identifying the user 
> data being passed with an IANA-registered string ('WebSocket Subprotocol Name Registry' defined in 
> [RFC6455]). I wouldn't see the out of band method using a different registry.

[Juergen] Agree.

>
>
> 5.1.1.4. max-retr parameter: This draft seems to use the absence of the "max-retr" parameter to 
> indicate the use of a reliable channel It also indicates a default value of "unbounded". 
> draft-ietf-rtcweb-data-protocol indicates "For reliable Data Channels this field MUST be set to 0 
> on the sending side and MUST be ignored on the receiving side."
> To better align with the data channel protocol i'd suggest changing the of 5.1.1.4 to indicate 
> that "The max-retr parameter is optional with the default value equal to 0 indicating that no 
> retramsmission is used.

[Juergen] Our current intention is that the absence of "max-retr" and "max-time" in the a=dcmap 
attribute value would indicate a reliable data channel, similar as channel types 
"DATA_CHANNEL_RELIABLE" and "DATA_CHANNEL_RELIABLE_UNORDERED" in DCEP's DATA_CHANNEL_OPEN message.
And that "max-retr=0" would actually indicate a partial reliable data channel with the maximal 
number of retransmissions set to zero (similar to DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT(_UNORDERED) 
and "Reliability Parameter" = 0 in the DATA_CHANNEL_OPEN message).
If we kept this semantic of "max-retr=0", then a default value equal to 0 would result in an a=dcmap 
attribute without "max-retr" parameter actually indicating a correspondingly partial reliable data 
channel, such that then the data channel would actually not be reliable as far as I understand.

>
> Also is the term "unreliable" appropriate given that the data channel protocol talks about 
> "partial reliability"?

[Juergen] Agree. We should replace "unreliable" with "partially reliable" throughout the document.

>
> 5.1.1.5 similar to 5.1.1.4 I think it would be better to talk about specific behaviour when the 
> parameter is omitted rather than saying "unbounded".

[Juergen] Agree. We should make this case more explicit and e.g. refer to RFC 4960 and say:
"The max-time parameter is optional. If the max-time parameter is not present, then the generic SCTP 
retransmission timing rules apply as specified in [RFC 4960]."

Similarly in 5.1.1.4; there we could e.g. say:
"The max-retr parameter is optional. If the max-retr parameter is not present, then the maximal 
number of retransmissions is determined as per the generic SCTP retransmission rules as specified in 
[RFC 4960]."

Would you agree to this?

>
> 6. Example: In the examples a=dcmap:0 subprotocol="BFCP";label="BGCP" lines. Is the B<G>CP for the 
> label intentional?

[Juergen] That's a typo. Should have been 'label="BFCP"'. We'll correct this.

>> Based on the discussion on list over the last few days, I have submitted revised versions of the 
>> two SDP negotiation over data channel drafts as follows:
>>

-- 
JSB_email_signature

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 Nov 2014 09:43:23 -1000

On 11/12/14 9:09 AM, Juergen Stoetzer-Bradler wrote:

> [Juergen] Actually, I am not sure if this would formally prevent
> maxretr-opt and maxtime-opt  from both being present simultaneously, as
> we would still have
> Right now don't see a "compact" way of strengthening the actual ABNF
> rules without having to list all possible parameter combinations and
> permutations.

Yes. I agree. There is no good way to do this in ABNF. One could get 
"closer", with something like:

    dcmap-value     = dcmap-stream-id
                      *(";" dcmap-non-max-opt)
                      [dcmap-max-opt]
                      *(";" dcmap-non-max-opt)
    dcmap-non-max-opt = ordering-opt / subprotocol-opt / label-opt
    dcmap-max-opt     = maxretr-opt / maxtime-opt

Note that this separates the stream-id from the opts with ";" rather 
than " ". (It would be much harder while preserving the space.)

But this still syntactically allows multiple use of the non-max-opts 
(e.g. multiple occurrences of ordering-opt.) So there is still a need 
for normative text to forbid that. IMO it is more straightforward to do 
all of these constraints in text.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Thu, 13 Nov 2014 11:06:42 +1100

Hello Juergen,

Thanks for your reply. Please see below.

Regards, Christian

..snip..
> maxretr-opt and maxtime-opt  from both being present simultaneously, 
> as we would still have
[CNG] Yes you're right. In other protocols this has been covered by an 
"At most once" statement on the ABNF. The ( ) would ensure that only one 
would be used.

>
> ..snip..
>>
>>
>> 5.1.1.4. max-retr parameter: This draft seems to use the absence of 
>> the "max-retr" parameter to indicate the use of a reliable channel It 
>> also indicates a default value of "unbounded". 
>> this field MUST be set to 0 on the sending side and MUST be ignored 
>> on the receiving side."
>> To better align with the data channel protocol i'd suggest changing 
>> the of 5.1.1.4 to indicate that "The max-retr parameter is optional 
>> with the default value equal to 0 indicating that no retramsmission 
>> is used.
>
> [Juergen] Our current intention is that the absence of "max-retr" and 
> "max-time" in the a=dcmap attribute value would indicate a reliable 
> data channel, similar as channel types "DATA_CHANNEL_RELIABLE" and 
> "DATA_CHANNEL_RELIABLE_UNORDERED" in DCEP's DATA_CHANNEL_OPEN message.
> And that "max-retr=0" would actually indicate a partial reliable data 
> channel with the maximal number of retransmissions set to zero 
> (similar to DATA_CHANNEL_PARTIAL_RELIABLE_REXMIT(_UNORDERED) and 
> "Reliability Parameter" = 0 in the DATA_CHANNEL_OPEN message).
> If we kept this semantic of "max-retr=0", then a default value equal 
> to 0 would result in an a=dcmap attribute without "max-retr" parameter 
> actually indicating a correspondingly partial reliable data channel, 
> such that then the data channel would actually not be reliable as far 
> as I understand.
[CNG] OK my point was that the behaviour should be defined better and 
your comment below covers it.

As an aside, is there a reason why the draft doesn't follow the 
parameter structure of I-D.ietf-rtcweb-data-channel if its trying to 
emulate the information? i.e. a channel type and a reliability 
parameter. With these two parameters it's clear what type of data 
channel is being asked for rather than relying on the absence of 
parameters and also avoids having to specify valid combinations. It 
would allow support of new types (via the IANA registry) without new 
parameters.

> ..snip..
> "The max-time parameter is optional. If the max-time parameter is not 
> present, then the generic SCTP retransmission timing rules apply as 
> specified in [RFC 4960]."
>
> "The max-retr parameter is optional. If the max-retr parameter is not 
> present, then the maximal number of retransmissions is determined as 
> per the generic SCTP retransmission rules as specified in [RFC 4960]."
>
> Would you agree to this?
[CNG] Yes
..snip..