Subject: Re: [clue] WGLC: draft-ietf-clue-datachannel-07 - ends 13 February - Paul's comments

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Feb 2015 08:48:29 +0000

Hi Paul,

Thanks for your comments! Reply inline.

> * Section 2:
>
>    WebRTC Data Channel refers to a SCTPoDTLS association
>    [I-D.ietf-tsvwg-sctp-dtls-encaps] that is used to transport non-media
>    data between two entities, according to the procedures in
>    [I-D.ietf-rtcweb-data-channel].
>
> IMO the above is wrong! IIUC "WebRTC Data Channel" refers to a single channel, namely a pair of SCTP streams, over an SCTPoDTLS association. 
> [I-D.ietf-rtcweb-data-channel] says:
>
>    The realization of a data channel is a pair of one incoming stream
>    and one outgoing SCTP stream having the same SCTP stream identifier.
>    How these SCTP stream identifiers are selected is protocol and
>    implementation dependent.  This allows a bidirectional communication.
>
> So I suggest the following to replace the above:
>
>    WebRTC Data Channel refers to a pair of SCTP streams over a
>    SCTPoDTLS association that is used to transport non-media
>    data between two entities, as defined in
>    [I-D.ietf-rtcweb-data-channel].

I'll fix as suggested.

> At the end of the section is:
>
>    [RFC4960] defines an SCTP stream as a unidirectional logical channel
>    established from one to another associated SCTP endpoint, within
>    which all user messages are delivered in sequence except for those
>    submitted to the unordered delivery service.
>
>    [RFC4960] defines an SCTP identifier as a unsigned integer, which
>    identifies a SCTP stream.
>
> I don't understand how to interpret these in context. The section is listing conventions. Does "[RFC4960]" name a convention? How about:
>
>    SCTP stream is defined in [RFC4960] as a unidirectional logical
>    channel established from one to another associated SCTP endpoint,
>    within which all user messages are delivered in sequence except for
>    those submitted to the unordered delivery service.
>
>    SCTP identifier is defined in [RFC4960] as a unsigned integer, which
>    identifies a SCTP stream.

I'll fix as suggested.

-------------------------

> * Section 3.2.1.2
>
> I think it would be good to mention that each CLUE entity is free to choose the sctp-port value at which it receives messages. CLUE does not prescribe any particular value.

I suggest the following modified paragraph text:

	   "As defined in [I-D.ietf-mmusic-sctp-sdp], the SDP sctp-port attribute
   	value is set to the SCTP port of the SCTPoDTLS association. A CLUE entity
	can choose any valid SCTP port value."

-------------------------

> * Section 3.2.2
>
> This starts with 'When the SDP-based "SCTP over DTLS" data channel negotiation mechanism is used ...'. This suggests that there may be some other way. How about:
>
>    The SDP-based "SCTP over DTLS" data channel negotiation
>    mechanism is used to establish a CLUE data channel.
>    The values of the ...

I'll fix as suggested.

-------------------------

> * Section 3.3.1
>
> I find table 3 to be confusing. In spite of the text to the contrary it seems to say that PPID 51 explicitly identifies CLUE. I suggest simply removing Table 3.

I can do that. I agree it's not really needed anymore.

-------------------------

> * Section 3.3.2
>
> I suggest modifying the 2nd paragraph as follows:
>
>    A CLUE entity MUST NOT use the partial reliability and limited
>    retransmission extensions (defined in [RFC3758], enabled with
>    the dcmap options 'max-retr' and 'max-time') for the CLUE
>    data channel.
>
> (Otherwise this might be read to forbid using these for other data
> channels.) Mark also commented on this.

Mark suggested the following text:

	"A CLUE data channel MUST NOT use the partial reliability and limited retransmission 
	SCTP extensions defined in [RFC3758]."

Personally I would suggest to use Mark's text, and not talk about the dcmap options in this section, which is about SCTP features and extensions.

-------------------------

> * Section 3.3.3
>
> I suggest revising this to read:
>
>    A CLUE entity MUST use the ordered delivery SCTP service, as
>    described in section 6.6 of [RFC4960]. This service is enabled
>    either by omitting the 'ordered' option from the dcmap attribute, or
>    by specifying 'ordered="1"' in the dcmap attribute.
>
> But this also keys into the other discussion of ordered. So make this conditional on that.

Again, it'd like to keep the dcmap attribute details out of section 3.3, and make sure section 3.2 is clear enough.

I have been thinking, though, whether it would be a good idea to switch the order of sections 3.2 and 3.3, in order to first talk about the SCTP extensions etc, and then talk about how to signal them.

-------------------------

> * Section 3.3.6
>
> I think this should say *both* streams making up the channel must be reset. When a reset is received on one stream, a reset MUST immediately be sent on the other stream of the channel. (Unless one has already been
> sent.)

Christian also had a comment (editorial) on this section.

I suggest to modify the paragraph as following:

	"As described in [I-D.ietf-rtcweb-data-protocol], in order to close a data channel, an entity sends an SCTP reset 
	message [RFC6525] is sent on its outgoing SCTP stream associated with the data channel. When the remote
	peer receives the reset message, it also sends (unless already sent) a reset message on its outgoing SCTP 
	stream associated with the data channel. The SCTPoDTLS association, and other data channels established on 
	the same association, are not affected by the SCTP reset messages."

-------------------------

> * Section 5.2
>
> I agree with others that the dcmap subprotocol value should utilize the same registry as used for DCEP.

Please provide your comments on the associated MMUSIC list thread :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Feb 2015 10:01:05 -0500

On 2/11/15 3:48 AM, Christer Holmberg wrote:

WFM

This may require some further discussion.

In draft-ietf-rtcweb-data-channel there is a presumption that there is 
an API used for accessing data channels. The API makes the options 
appear to the user as being per-channel, even though in the SCTP 
protocol they are per-message.

Similarly the ejzak draft negotiates them on a per-channel basis, and 
assumes that they will be used that way.

I don't know if we are assuming that clue implementations will be using 
an API that preserves this per-channel behavior, or if we are assuming 
that the clue implementer will need to take the negotiated values and 
apply them on a per-message basis.

The bottom line is that we prescribe which options must be negotiated 
for the clue channel, and then we require that the streams be used in a 
way that is consistent with those options.

Of course my comment above applies here too.

Intent above seems fine. But the language isn't quite right: "an entity 
sends ... is sent" is broken. I think you can simply delete "is sent".

I think I did.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Feb 2015 19:26:34 +0000

Hi,

* Section 3.2.1.2

>>> I think it would be good to mention that each CLUE entity is 
>>> free to choose the sctp-port value at which it receives messages. CLUE does not prescribe any particular value.
>>

I'll modify as suggested.

------------------------

* Section 3.3.2

>> Personally I would suggest to use Mark's text, and not talk about the dcmap options 
>> in this section, which is about SCTP features and extensions.
>
> In draft-ietf-rtcweb-data-channel there is a presumption that there is an API used 
> for accessing data channels. The API makes the options appear to the user as being 
> per-channel, even though in the SCTP protocol they are per-message.
>
> Similarly the ejzak draft negotiates them on a per-channel basis, and assumes that they will be used that way.
>
> I don't know if we are assuming that clue implementations will be using an API that preserves this 
> per-channel behavior, or if we are assuming that the clue implementer will need to take the negotiated 
> values and apply them on a per-message basis.

I think we should not make assumptions what API is used. 

(Unfortunately, draft-data-channel seems to be focused mostly about browsers and WebRTC.)

> The bottom line is that we prescribe which options must be negotiated for the clue channel, and then
> we require that the streams be used in a way that is consistent with those options.

We could, odd a note, and inform people that according to [ref-to-data-channel] the SCTP options are applied per channel, i.e. to each message sent on a channel.

* Section 3.3.3

>> I have been thinking, though, whether it would be a good idea to switch the order of 
>> sections 3.2 and 3.3, in order to first talk about the SCTP extensions etc, and then talk about how to signal them.
>

Correct.

However, it seems like your comment is not related to my suggestion of not talking about dcmap in section 3.3 :)

Do you have an opinion on switching sections 3.2 and 3.3? 

* Section 3.3.6

>>> I think this should say *both* streams making up the channel must be 
>>> reset. When a reset is received on one stream, a reset MUST 
>>> immediately be sent on the other stream of the channel. (Unless one 
>>> has already been sent.)
>>
> Intent above seems fine. But the language isn't quite right: "an entity sends ... is sent" is broken. I think 
> you can simply delete "is sent".

 	message [RFC6525] on its outgoing SCTP stream associated with the data channel. When the remote

* Section 5.2

>> Please provide your comments on the associated MMUSIC list thread :)

I know. It was a meant to the whole community :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Feb 2015 16:41:18 -0500

Yes.

Not specifically. But something needs to relate the two sections: the 
options used when sending messages need to be consistent with what is 
negotiated. Pretending that those two things are unrelated is confusing.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Feb 2015 07:34:46 +0000

Hi,

------------------------

* Section 3.3.2

>>>> Personally I would suggest to use Mark's text, and not talk about 
>>>> the dcmap options in this section, which is about SCTP features and extensions.
>>>
>>> In draft-ietf-rtcweb-data-channel there is a presumption that there 
>>> is an API used for accessing data channels. The API makes the options 
>>> appear to the user as being per-channel, even though in the SCTP protocol they are per-message.
>>>
>>> I don't know if we are assuming that clue implementations will be 
>>> using an API that preserves this per-channel behavior, or if we are 
>>> assuming that the clue implementer will need to take the negotiated values and apply them on a per-message basis.
>>
>>> for the clue channel, and then we require that the streams be used in a way that is consistent with those options.
>>

Will be done.

* Section 3.3.3

>>>> I have been thinking, though, whether it would be a good idea to 
>>>> switch the order of sections 3.2 and 3.3, in order to first talk about the SCTP extensions etc, and then talk about how to signal them.
>>>
>> However, it seems like your comment is not related to my suggestion of 
>> not talking about dcmap in section 3.3 :)
>>
> Not specifically. But something needs to relate the two sections: the options used when sending messages need to be consistent with what is negotiated. Pretending that those two things are unrelated is confusing.

I agree. We could have a sentence in the SCTP considerations section, saying something like: "Section 3.x describes how the SCTP properties and extensions are negotiated using the sdp-neg mechanism."

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Feb 2015 10:46:56 +0000

Hi,

New suggestion on how to address one of Paul's comments.

* Section 3.2.2

>>    mechanism is used to establish a CLUE data channel.

I suggest to only say:

	"The values of the SDP dcmap attribute [I-D.ietf-mmusic-data-channel-sdpneg], 
	associated with the m- line describing the SCTPoDTLS association used to realize 
	the WebRTC Data Channel, are set as following:"

At the same time I suggest to modify the first paragraph in section 3.2.1. to:

	"This section defines how to construct the SDP Media Description
	(m- line) for describing the SCTPoDTLS association used to realize
	a WebRTC Data Channel. The section also defines how to use the 
	SDP-based "SCTP over DTLS" data  channel negotiation mechanism 
	[I-D.ietf-mmusic-data-channel-sdpneg] for establishing a CLUE Data 
	Channel on the SCTPoDTLS association."

Because, as section 3.2.1 already says that the sdpneg mechanism is used, there is no need to repeat 
that in section 3.2.2.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 12 Feb 2015 11:09:37 +0000

Hi,

------------------------

* Section 3.3.2

>>>> is an API used for accessing data channels. The API makes the 
>>>> options appear to the user as being per-channel, even though in the SCTP protocol they are per-message.
>>>>
>>>> The bottom line is that we prescribe which options must be 
>>>> negotiated for the clue channel, and then we require that the streams be used in a way that is consistent with those options.
>>>

See my suggestion below, which should also cover this issue.

* Section 3.3.3

>>> However, it seems like your comment is not related to my suggestion 
>>> of not talking about dcmap in section 3.3 :)
>>>

I suggest the following new SCTP considerations subsection:

	"3.2.1.  General

	   As described in [I-D.ietf-rtcweb-data-channel], different SCTP
	   options (e.g. regarding ordered delivery ), can be used for a data
	   channel.  This section describes the SCTP options used for a CLUE
	   data channel.  Section 3.3 describes how SCTP options are signalled
	   using SDP.

	   NOTE: While SCTP allows SCTP options to be applied per SCTP message,
	   [I-D.ietf-rtcweb-data-channel] mandates that, for a given data
	   channel, the same SCTP options are applied to each SCTP message
	   associated with that data channel."

Regards,

Christer