Subject: [clue] Draft new version: clue-data-channel-01

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Sep 2014 13:29:28 +0000

Hi,

I've submitted a new version of the CLUE data channel draft.

The changes are mostly editorial: I structured the O/A procedures according to 3264, and updated the references.

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Tue, 16 Sep 2014 11:12:47 +1000

Hello Christer,

Just a question on 5.7 where it says "If an offerer wants to disable the 
CLUE Data Channel in an offer, it assigns a zero port value to the "m=" 
line representing the SCTPoDTLS association used to realize the CLUE 
Data channel."

Wouldn't this have the effect of closing the SCTP/DTLS association 
causing CLUE AND any other protocols to be disabled? Clause 5.7 and 5.8 
seem to be for a generic webrtc data channel. To have a "CLUE data 
channel" we use the a=group.

i.e. Generic Data Channel
m=application 54111 SCTP/DTLS 54111
a=sctpmap:54111 webrtc-datachannel

CLUE data channel
a=group:CLUE 100
m=application 54111 SCTP/DTLS 54111
a=sctpmap:54111 webrtc-datachannel
a=mid:100

Therefore if an endpoint wanted to remove CLUE from the data channel 
(without closing the SCTP/DTLS associated) it would remove the a=group 
and a=mid.

There's also a typo in clause 5.7 "are unchanged" is repeated.

Regards, Christian

On 15/09/2014 11:29 PM, Christer Holmberg wrote:
>
> Hi,
>
> I’ve submitted a new version of the CLUE data channel draft.
>
> The changes are mostly editorial: I structured the O/A procedures 
> according to 3264, and updated the references.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 16 Sep 2014 17:03:20 +0000

Hi Christian,

I am not sure I agree with what you are saying.

Sure, we can use the grouping to indicate that the SCTPoDTLS association will be used within a CLUE session.

But, in order to open a data channel for CLUE, you need to use DCEP. Also, in order to close a data channel for CLUE, you need to reset the STCPoDTLS association. Just removing the m= line from the CLUE group won't do that - and I am not even sure we should allow that.

Also, if we use a mid attribute to associate the SCTPoDTLS association with CLUE, can we then also use it for non-CLUE protocol? Does not seem semantically correct in my opinion. 

Regards,

Christer

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: 16 September 2014 04:13
To: [email-masked]
Subject: Re: [clue] Draft new version: clue-data-channel-01

Hello Christer,

Just a question on 5.7 where it says "If an offerer wants to disable the CLUE Data Channel in an offer, it assigns a zero port value to the "m=" 
line representing the SCTPoDTLS association used to realize the CLUE Data channel."

Wouldn't this have the effect of closing the SCTP/DTLS association causing CLUE AND any other protocols to be disabled? Clause 5.7 and 5.8 seem to be for a generic webrtc data channel. To have a "CLUE data channel" we use the a=group.

CLUE data channel
a=group:CLUE 100

Therefore if an endpoint wanted to remove CLUE from the data channel (without closing the SCTP/DTLS associated) it would remove the a=group and a=mid.

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 16 Sep 2014 13:34:13 -0400

Christer,

We had a design team call today and discussed fallback.

Bottom line (my interpretation from the discussion):

If you negotiate the sctp association *and* include it in the clue 
group, you are saying that you *intend* to enable clue. Of course you 
still have to use DCEP to open the clue channel, but it is expected that 
you will do that.

If you want to fallback, and you still want to retain the sctp 
association for other purposes, then you need to:
- close the clue data channel (sctp stream)
- use O/A to remove the sctp association from the clue group

If you want to fallback, and you don't want to retain the sctp 
association, then you can:
- use O/A to remove the sctp association (port 0)
- terminate the actual sctp association
- (I think you can do the above in either order)
- it would be nice if you closed the clue data channel first,
   but probably not necessary to do so.

If the sctp association is closed for some reason, and you want to 
remain clue enabled, then you should:
- send another offer including the sctp m-line in the clue group
- start things up again
- (I think you don't try to reestablish the association until
   the new offer is sent.)

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Wed, 17 Sep 2014 11:12:46 +1000

Hello Christer,

I think Paul has covered the issue with regards to fall back. We have to 
distinguish between the overall data channel and the resultant streams 
being used for CLUE. DCEP doesn't open the overall SCTP/DTLS association 
it establishes a protocol on a certain stream/s. Closure is done by 
resetting the stream (see clause 6.7/draft-ietf-rtcweb-data-channel-11) 
not by resetting the whole SCTP/DTLS association.

With regards to the SCTP/DTLS association my understanding of the WebRTC 
datachannel is that you can use several application protocols within 
that association, i.e. CLUE and say BFCP. I think think we can say that 
an SCTP/DTLS association must only contain CLUE. I think its valid to 
use an mid in multiple groups. RFC5888 clause 6 says "An "m" line 
identified by its "mid" attribute MAY appear in more than one "a=group" 
line."

Regards, Christian

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Sep 2014 07:11:14 +0000

Hi Paul,

>We had a design team call today and discussed fallback.

I know. Unfortunately I wasn't able to attend, due to some personal issues  :(

>If you negotiate the sctp association *and* include it in the clue group, you are saying that you *intend* to enable clue. Of course you still have to use DCEP to open the clue channel, but it is expected that you will do that.

Correct.

>If you want to fallback, and you still want to retain the sctp association for other purposes, then you need to:

Correct.

I do think we need to have some text on what happens if one removes the sctp association from the clue group - WITHOUT closing the clue data channel first. In my opinion it is an error case, but I think we should say that one MUST NOT send CLUE messages on such stream, and MUST discard any CLUE message received on such stream.

>If you want to fallback, and you don't want to retain the sctp association, then you can:

Correct.

But, one of my question (which is not specific to fallback) was: if we associate the SCTP association with the CLUE group, would it be semantically correct to also use the SCTP association for non-CLUE purpose (technically there is no problem)?

>If the sctp association is closed for some reason, and you want to remain clue enabled, then you should:
   the new offer is sent.)

Regarding the last point, I guess that should be covered in the sctp-sdp draft.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Sep 2014 07:16:42 +0000

Hi,

>I think Paul has covered the issue with regards to fall back. We have to distinguish between the overall data channel and the resultant streams being used for CLUE. DCEP doesn't open the overall SCTP/DTLS association it establishes a protocol on a certain stream/s. Closure is done by >resetting the stream (see clause 6.7/draft-ietf-rtcweb-data-channel-11) not by resetting the whole SCTP/DTLS association.

I agree. 

I guess my concern was triggered by the fact that the design team minutes did not mention the resetting of the stream - only the removal of the sctp association from the CLUE group.

>With regards to the SCTP/DTLS association my understanding of the WebRTC datachannel is that you can use several application protocols within that association, i.e. CLUE and say BFCP. I think think we can say that an SCTP/DTLS association must only contain CLUE.

I agree, and the clue data channel draft currently says that.

> I think its valid to use an mid in multiple groups. RFC5888 clause 6 says "An "m" line identified by its "mid" attribute MAY appear in more than one "a=group"  line."

That is also true, but other users of the sctp association may not have any groups associated... Again, it is not a technical problem, but more semantical.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Sep 2014 09:44:54 -0400

> I do think we need to have some text on what happens if one removes the sctp association from the clue group - WITHOUT closing the clue data channel first. In my opinion it is an error case, but I…

agree.

> But, one of my question (which is not specific to fallback) was: if we associate the SCTP association with the CLUE group, would it be semantically correct to also use the SCTP association for non-…

If we want the possibility of sharing the use of the association then 
this must be valid.

How the application determines what else the association is used for is 
out of scope for clue.

> Regarding the last point, I guess that should be covered in the sctp-sdp draft.

I think this is implicitly inherited by SCTP from the definition of 
comedia. (RFC4145). But it would probably be good to spell it out.

At least for TCP, the issue is whether the app needs to maintain a 
listener for new connections after the initial connection has been 
established. (The mechanics for SCTP may be different, especially SCTP 
over DTLS, because it is an application layer stack rather than a socket 
interface.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Sep 2014 09:51:20 -0400

On 9/16/14 9:12 PM, Christian Groves wrote:
> being used for CLUE.

We need to use terminology consistently. In your sentence above you 
mention "overall data channel". I infer you are talking about the SCTP 
association. IMO it is inappropriate to refer to that as a data channel.

IIUC a data channel is a pair of SCTP streams, one in each direction, 
while the only term for the collection of all of the streams is SCTP 
association.

	Thanks,
	Paul

> DCEP doesn't open the overall SCTP/DTLS association
>> Sure, we can use the grouping to indicate that the SCTPoDTLS
>> association will be used within a CLUE session.
>>
>> But, in order to open a data channel for CLUE, you need to use DCEP.
>> Also, in order to close a data channel for CLUE, you need to reset the
>> STCPoDTLS association. Just removing the m= line from the CLUE group
>> won't do that - and I am not even sure we should allow that.
>>
>> Also, if we use a mid attribute to associate the SCTPoDTLS association
>> with CLUE, can we then also use it for non-CLUE protocol? Does not
>> seem semantically correct in my opinion.
>>
>> Regards,
>>
>> Christer
>>
>> Just a question on 5.7 where it says "If an offerer wants to disable
>> the CLUE Data Channel in an offer, it assigns a zero port value to the
>> "m="
>> causing CLUE AND any other protocols to be disabled? Clause 5.7 and
>> 5.8 seem to be for a generic webrtc data channel. To have a "CLUE data

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 17 Sep 2014 18:56:14 +0000

Hi,

...

>> But, one of my question (which is not specific to fallback) was: if we associate the SCTP association >> with the CLUE group, would it be semantically correct to also use the SCTP association for non-
>> CLUE purpose (technically there is no problem)?
>
> If we want the possibility of sharing the use of the association then this must be valid.

I guess we could think about whether the SCTP association really needs to be within the CLUE group.

The main purpose of the CLUE group is to indicate which media is CLUE controlled.

Is it really that important to associate the SCTP association with the CLUE group? After all, what matters is whether you have established a CLUE data channel (using DCEP) on that SCTP association or not...

Regards,

Christer

> Regarding the last point, I guess that should be covered in the sctp-sdp draft.

I think this is implicitly inherited by SCTP from the definition of comedia. (RFC4145). But it would probably be good to spell it out.

At least for TCP, the issue is whether the app needs to maintain a listener for new connections after the initial connection has been established. (The mechanics for SCTP may be different, especially SCTP over DTLS, because it is an application layer stack rather than a socket
interface.)

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Sep 2014 15:26:26 -0400

> Is it really that important to associate the SCTP association with the CLUE group? After all, what matters is whether you have established a CLUE data channel (using DCEP) on that SCTP association…

I see no problem with including it in the clue group as long as we 
specify what that means to us.

I can think of at least two reasons why we want/need it in the clue group:

1) In the initial offer, it may be the *only* thing in the clue group. I 
think we need it to be clear we are clue enabled.

2) If it happened that there were multiple SCTP associations, the clue 
group is how we know which one is to contain the clue channel.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Sep 2014 09:35:58 +0000

Hi,

>>>> But, one of my question (which is not specific to fallback) was: if 
>>>> we associate the SCTP association >> with the CLUE group, would it be semantically correct to also use the SCTP association for non- CLUE purpose (technically there is no problem)?
>>>
> I see no problem with including it in the clue group as long as we specify what that means to us.
>
> 1) In the initial offer, it may be the *only* thing in the clue group. I think we need it to be clear we are clue enabled.

In my opinion, the media feature tag indicates that we support CLUE, and once you've established the CLUE data channel we have enabled clue.

> 2) If it happened that there were multiple SCTP associations, the clue group is how we know which one is to contain the clue channel.

I was thinking about that, but I think that is a more generic problem, affecting whatever protocol you are going to use on the data channel(s). Also, maybe you don't care on which SCTP association you open the CLUE channel.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 18 Sep 2014 13:24:14 -0400

> In my opinion, the media feature tag indicates that we support CLUE, and once you've established the CLUE data channel we have enabled clue.

The media feature tag indicates that you have the *capability* to do 
CLUE. It doesn't indicate that you want to do it.

The discussion we had on Tuesday indicates the importance of having a 
way to signal that an SCTP association being offered it intended to be 
used to *enable* clue.

> I was thinking about that, but I think that is a more generic problem, affecting whatever protocol you are going to use on the data channel(s). Also, maybe you don't care on which SCTP association…

The other protocols aren't our problem.
The clue group solves it for CLUE. Others can use a similar approach if 
they want, or do something else.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Fri, 19 Sep 2014 10:18:44 +1000

Hello Paul,

I wasn't proposing updated terminology. I was just trying to illustrate 
the issue to Christer and he seems to have understood me.

Regards, Christian