Subject: [clue] Draft new version: draft-holmberg-clue-datachannel-01

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Feb 2014 12:12:55 +0000

Hi,

Based on the discussions on the CLUE- and RTCWEB lists, I've submitted a new version of the CLUE data channel draft.

There are still open issue, and I have probably not implemented everyone's change wishes. It is more to add some more meat, and continue the discussions.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Feb 2014 12:20:22 -0500

On 2/7/14 7:12 AM, Christer Holmberg wrote:
> Hi,
>
> Based on the discussions on the CLUE- and RTCWEB lists, I’ve submitted a
> new version of the CLUE data channel draft.
>
> There are still open issue, and I have probably not implemented
> everyone’s change wishes. It is more to add some more meat, and continue
> the discussions.

Thanks. Much of the confusing points are getting clarified!

A few comments:

Actually there are two open issues, one in 3.2, one in 3.3.

I think you can resolve the one in 3.2, and just say the the SCTP 
streams IDs must be identical. If we use the rtcweb channel protocol 
then that will be true. If we use the ejzak draft it will also be true. 
And if we define our own negotiation mechanism then we can make it be true.

Section 3.4.1:

Must use 51 or 54 for CLUE protocol messages.
If we end up using the RTCWEB Data Channel Protocol then we will also be 
using 50.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Feb 2014 22:21:45 +0000

Hi Paul,

Again, thanks for your quick comments!

> Actually there are two open issues, one in 3.2, one in 3.3.

Yes - I meant to say open issueS :)

> And if we define our own negotiation mechanism then we can make it be true.

True. BUT, we need to be sure that a CLUE JavaScript application can actually control the stream id values being used.

If the DCP is used, it is taken care of by the browser.

> If we end up using the RTCWEB Data Channel Protocol then we will also be

Correct.

And, as has been indicated on the RTCWEB list, value 54 will be deprecated (as fragmentation will not be done on application level).

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Feb 2014 17:53:07 -0500

> True. BUT, we need to be sure that a CLUE JavaScript application can actually control the stream id values being used.

I think you already got a response to your question about that on the 
rtcweb list, explaining how to do it.

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Feb 2014 22:57:08 +0000

Hi,

>I think you already got a response to your question about that on the rtcweb list, explaining how to do it.

Can you provide a link to that e-mail?

I am at home, using a web mail client, which is awful for scanning through e-mail threads :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Feb 2014 18:16:04 -0500

> Can you provide a link to that e-mail?

http://www.ietf.org/mail-archive/web/rtcweb/current/msg11299.html

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 7 Feb 2014 23:36:23 +0000

Hi,

> http://www.ietf.org/mail-archive/web/rtcweb/current/msg11299.html

Thanks for the link!

Ok, I remember that e-mail. It seems like he wasn't 100% sure, though, so it needs to be verified :)

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Mon, 10 Feb 2014 11:42:42 +1100

Hello Christer,

Thanks for updating the draft. It looks better with more meat on it.

Some comments/questions:

3.2 Para.2 - I've raised this before "is it possible to have multiple 
CLUE bi-directional CLUE Data Channels per SCTP association"? I can't 
think of a case where this would be needed??? If its not needed then I 
would suggest a slight update to make this clear, i.e.
" The realization of a bidirectional CLUE Data Channel is a pair of one
incoming SCTP stream and one outgoing SCTP stream <<per SCTP 
association>>. These streams are
then used to transport CLUE messages in both directions."

3.2 Para.4 - Is this a MUST or a SHOULD? To me there are no exceptions 
to a MUST, in the sentence we list an exception that allows the use of 
another id.

3.4.1 - I guess now we'll only specify the new PID value indicating 
UTF-8 (and 50 for WebRTC if used) based on recent discussions on the 
RTCWeb list?

3.4.2 - "CLUE entities MUST use the reliable transport SCTP feature." 
This sounds like there is a special service or function for this? I 
thought reliability is inherent to SCTP? May we could reword to 
something like "CLUE entities must support the SCTP which ensures 
reliable transport of CLUE messages."
If you wanted to be more specific with regards to RTCweb data protocol 
you could add something like: "In the context of 
[ID.ietf-rtcweb-data-protocol] the use of a "DATA_CHANNEL_RELIABLE" 
channel."

3.4.3 - I propose to be a bit more concrete:
"CLUE entities MUST use the ordered delivery SCTP <<service as described 
by section 6.6/[RFC 2960]>>.

3.4.5 - I think there are dodgy reference, interleaving is described in 
<I-D.stewart-tsvwg-sctp-ndata>.

6 - I mentioned earlier that if we use RTCWEB data channel we need to 
define CLUE as a protocol. So I propose adding something like:

[ID.ietf-rtcweb-data-protocol] defines a new "Protocol Registry" for the 
data channel protocol to manage the "Protocol" field of type string in 
DATA_CHANNEL_OPEN messages. If CLUE is [ID.ietf-rtcweb-data-protocol] is 
used a new protocol value for CLUE is required.
The following values need to be registered:

+--------------+-----------+
| Name | Reference |
+--------------+-----------+
| CLUE | [RFCXXXX] |
+--------------+-----------+

[RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this
document.]

Note: [ID.ejzak-dispatch-webrtc-data-channel-sdpneg] also contains a 
"sub-protocol" parameter. The IANA registry that will be used for 
recording the protocols is still under discussion. "CLUE" should also be 
registered in this registry.

Regards, Christian

On 7/02/2014 11:12 PM, Christer Holmberg wrote:
>
> Hi,
>
> Based on the discussions on the CLUE- and RTCWEB lists, I’ve submitted 
> a new version of the CLUE data channel draft.
>
> everyone’s change wishes. It is more to add some more meat, and 
> continue the discussions.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 07:18:59 +0000

Hi Christian,

> Some comments/questions:
>
> 3.2 Para.2 - I've raised this before "is it possible to have multiple CLUE bi-directional CLUE Data Channels per SCTP association"? I can't think of a
> case where this would be needed??? If its not needed then I would suggest a slight update to make this clear, i.e.
> "The realization of a bidirectional CLUE Data Channel is a pair of one incoming SCTP stream and one outgoing SCTP stream <<per SCTP 
> association>>. These streams are then used to transport CLUE messages in both directions."

Eventhough I can't think of a case either, I am not sure whether we need to forbid having multiple CLUE channels per SCTP association. But, I think we should NOT allow using multiple CLUE channels in a single CLUE session.

> 3.2 Para.4 - Is this a MUST or a SHOULD? To me there are no exceptions to a MUST, in the sentence we list an exception that allows the use of another id.

It is currently a MUST.

But, we need to verify that e.g. JavaScript applications do have full control of setting the stream id value.

> UTF-8 (and 50 for WebRTC if used) based on recent discussions on the RTCWeb list?

Correct. 

In the next version of the draft I will use a "XX" value, which will be replaced with whatever value RTCWEB registers for UTF-8 strings.

>This sounds like there is a special service or function for this? I thought reliability is inherent to SCTP? May we could reword to something like "CLUE entities must support the SCTP which ensures reliable transport of CLUE messages."

Ok.

> If you wanted to be more specific with regards to RTCweb data protocol you could add something like: "In the context of [ID.ietf-rtcweb-data-protocol] the use of a "DATA_CHANNEL_RELIABLE" 
> channel."

I'd suggest we leave that until we have determined whether we will use the rtcweb data protocol.

> "CLUE entities MUST use the ordered delivery SCTP <<service as described by section 6.6/[RFC 2960]>>.

Ok.

> 3.4.5 - I think there are dodgy reference, interleaving is described in <I-D.stewart-tsvwg-sctp-ndata>.

Will be fixed.

> 6 - I mentioned earlier that if we use RTCWEB data channel we need to define CLUE as a protocol. So I propose adding something like:
>
> [ID.ietf-rtcweb-data-protocol] defines a new "Protocol Registry" for the data channel protocol to manage the "Protocol" field of type string in 
> DATA_CHANNEL_OPEN messages. If CLUE is [ID.ietf-rtcweb-data-protocol] is used a new protocol value for CLUE is required.
> [RFC EDITOR NOTE: Please replace RFC-XXXX with the RFC number of this document.]

I can mention in in section 3.3. But, again, until we have decided whether we will use the protocol or not, we don't need to specify too much.

> Note: [ID.ejzak-dispatch-webrtc-data-channel-sdpneg] also contains a "sub-protocol" parameter. The IANA registry that will be used for recording the protocols is still under discussion. "CLUE" should also be registered in this registry.

Assuming we'll use the draft, yes.

Thanks!

Regards,

Christer

On 7/02/2014 11:12 PM, Christer Holmberg wrote:
>
> Hi,
>
> Based on the discussions on the CLUE- and RTCWEB lists, I've submitted 
> everyone's change wishes. It is more to add some more meat, and

---

From: Christian Groves <[email-masked]>
Date: Mon, 10 Feb 2014 22:26:40 +1100

Hello Christer,

Please see below.

Regards, Christian

> Eventhough I can't think of a case either, I am not sure whether we need to forbid having multiple CLUE channels per SCTP association. But, I think we should NOT allow using multiple CLUE channels…
[CNG] A single CLUE session is signified by a single CLUE data channel 
which is a pair of SCTP streams, correct?

Having a single CLUE session (or any other bearer level application 
protocol) per SCTP association would certainly simplify things in 
gateways. If there are going to be multiple instances there's going to 
need to be more co-ordination of SCTP stream numbers vs protocol instances.

..snip..

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 11:44:24 +0000

Hi,

>>> CLUE bi-directional CLUE Data Channels per SCTP association"? I can't think of a case where this would be needed??? If its not needed then I would suggest a slight update to make this clear, i.e.
>>> "The realization of a bidirectional CLUE Data Channel is a pair of 
>>> one incoming SCTP stream and one outgoing SCTP stream <<per SCTP
>>> association
>>>. These streams are then used to transport CLUE messages in both directions."
>[CNG] A single CLUE session is signified by a single CLUE data channel which is a pair of SCTP streams, correct?

Correct.

>Having a single CLUE session (or any other bearer level application protocol) per SCTP association would certainly simplify things in gateways. If there are going to be multiple instances there's going to need to be more co-ordination of >SCTP stream numbers vs protocol instances.

Well, it IS allowed to have multiple instances per SCTP association, so in general you can't avoid that. But, in CLUE we can for sure restrict the number of CLUE data channels to one per SCTP association.

However, as you may have seen on the RTCWEB list, at least when using the DCP there is no way to prevent the establishment of TWO data channels, if both endpoints create one at the same time. That may not be an issue for CLUE, though, if we don't use the DCP, AND/OR we specify which endpoint is responsible for opening the data channel. It could e.g. be based on offerer/answer role, DTLS role, etc.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Feb 2014 09:56:42 -0500

Regarding use of data channel protocol vs. ejzak draft:

I think there is a tradeoff:

- using data channel protocol will probably be substantially easier
   for an rtcweb client. And I think we are more confident that
   the data channel protocol will become an RFC. (RTCWEB doesn't
   *need* the ejzak draft. It could just fade away.)

- but using the ejzak draft allows negotiating the use of CLUE
   in the SDP O/A. With data channel protocol, there is no indication
   of that until after the SCTP association has been established.
   (You might get that far, and then discover the other end intended
   to use the SCTP for something else, and doesn't do clue.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Feb 2014 10:36:34 -0500

Christian,

I hate to get over-prescriptive about what an application can do with 
other channels on the sctp association.

We have yet to stitch all the pieces together. Clearly it is necessary 
for the application to have a way to identify the particular channel 
that will be used to control the clue session. This is a general problem 
for rtcweb.

In the data channel protocol each channel has a protocol and a label.
In the Ejzak draft each channel has a subprotocol and a label.

(AFAIK 'protocol' and 'subprotocol' above are the same thing.)

I believe the expectation is in general that there can be several 
channels with the same (sub)protocol, and that they are intended to be 
referenced individually by 'label'.

One possibility is that we standardize a particular label value that 
identifies the channel used in a clue session. Another is that we use 
some new clue-specific SDP syntax to negotiate the which channel is used 
for CLUE.

	Thanks,
	Paul

On 2/10/14 6:26 AM, Christian Groves wrote:
>>> think of a
>>> case where this would be needed??? If its not needed then I would
>>> suggest a slight update to make this clear, i.e.
>> Eventhough I can't think of a case either, I am not sure whether we
>> need to forbid having multiple CLUE channels per SCTP association.
>> But, I think we should NOT allow using multiple CLUE channels in a
>> single CLUE session.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Feb 2014 10:38:28 -0500

> However, as you may have seen on the RTCWEB list, at least when using the DCP there is no way to prevent the establishment of TWO data channels, if both endpoints create one at the same time. That…

If we use DCP, then we should address how to avoid that, or what to do 
if it occurs.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 16:46:13 +0000

Hi,

>   to use the SCTP for something else, and doesn't do clue.)

Without using ANY of the above, the sctp-sdp mechanism allows you to negotiate a "webrtc-datachannel", but obviusly not the application(s) using the data channel.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Feb 2014 12:03:06 -0500

> Without using ANY of the above, the sctp-sdp mechanism allows you to negotiate a "webrtc-datachannel", but obviusly not the application(s) using the data channel.

And if we choose to use DCP to negotiate the clue channel then we will 
need to use that SDP. And with that we won't know if the app supports CLUE.

(I hope that "webrtc-datachannel" gets renamed, removing the "webrtc". 
It is inappropriate for us.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 20:08:02 +0000

Hi,

> And if we choose to use DCP to negotiate the clue channel then we will need to use that SDP. And with that we won't know if the app supports CLUE.

There are other mechanisms to indicate support of a feature. Media feature tags, etc. And, if we say that all CLUE entities MUST support the data channel, you don't need to explicitly indicate it on SDP level.

> (I hope that "webrtc-datachannel" gets renamed, removing the "webrtc". It is inappropriate for us.)

Well, it's just a value - but I agree it could be more generic.

Regards,

Christer

>>> 3.2 Para.2 - I've raised this before "is it possible to have 
>>> multiple CLUE bi-directional CLUE Data Channels per SCTP association"? I can't think of a case where this would be needed??? If its not needed then I would suggest a slight update to make this clear, i.e.
>>> [ID.ietf-rtcweb-data-protocol] defines a new "Protocol Registry" for 
>>> the data channel protocol to manage the "Protocol" field of type string in DATA_CHANNEL_OPEN messages. If CLUE is [ID.ietf-rtcweb-data-protocol] is used a new protocol value for CLUE is required.
>>> Based on the discussions on the CLUE- and RTCWEB lists, I've 
>>> submitted a new version of the CLUE data channel draft.
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Feb 2014 15:29:05 -0500

On 2/10/14 3:08 PM, Christer Holmberg wrote:
> There are other mechanisms to indicate support of a feature. Media feature tags, etc.

Yes, we could adopt one of those techniques to indicate desire for a 
clue session.

> And, if we say that all CLUE entities MUST support the data channel, you don't need to explicitly indicate it on SDP level.

You need to establish the SCTP association, so you have at least that 
SDP - an m-line and an a=sctpmap attribute. the sctp-sdp draft isn't 
clear whether the a=sctpmap is required, but I think it probably is if 
you are going to use the data channel protocol.

In any case, we must figure out definitively how to choose *which* sctp 
association is to be used.

> Well, it's just a value - but I agree it could be more generic.

It's just esthetic, but it is annoying.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Feb 2014 20:38:02 +0000

Hi,

> Yes, we could adopt one of those techniques to indicate desire for a clue session.
>
> You need to establish the SCTP association, so you have at least that SDP - an m-line and an a=sctpmap attribute. the sctp-sdp draft isn't clear whether the a=sctpmap is required, but I think it probably is if you are going to use the data channel protocol.

My understanding is that the sctpmap is required (the value indicating the number of streams is optional). If not, we can always specify that CLUE entities MUST use it.

> In any case, we must figure out definitively how to choose *which* sctp association is to be used.

Actually, from what I've heard, there is going to be a change to the sctp-sdp draft, so that only one SCTP association is allowed. 

If that is true, unless we create multiple m- lines with data channels, we will know which association to use.

Regards,

Christer