Subject: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require?

From: Christer Holmberg <[email-masked]>
Date: Tue, 4 Feb 2014 14:29:26 +0000

Hi,

Christian earlier suggested that we could copy/paste section 6.1 from the rtcweb-data-channel draft into our draft.

I think we need to consider whether we really need the features listed in that chapter (unless, of course, the usage of them is mandated in order to be compatible with rtcweb).

The features are listed below, with some initial comments ([CHH]).

   o  The stream reset extension defined in [RFC6525] MUST be supported.
      It is used for closing channels.

[CHH] I may have misunderstood RFC6526, but I don't think this is for CLOSING channels. It's for reseting the number sequence, which I think is a different thing.

In any case, I currently see no reason why we would need to mandate support of this in CLUE. [/CHH]

   o  The dynamic address reconfiguration extension defined in [RFC5061]
      MUST be used to signal the support of the stream reset extension
      defined in [RFC6525], other features of [RFC5061] MUST NOT be
      used.

[CHH] It seems like this is only used for the reset extension. The other features are related to multi-homing, which is not supported by SCTPoDTLS to begin with. [/CHH]

   o  The partial reliability extension defined in [RFC3758] MUST be
      supported.  In addition to the timed reliability PR-SCTP policy
      defined in [RFC3758], the limited retransmission policy defined in
      [I-D.tuexen-tsvwg-sctp-prpolicies] MUST be supported.

[CHH] I see no reason for support of partial reliability - eventhough I have to admit I am not sure what it really means. In any case, my suggestion is that CLUE always use "full" reliability. [/CHH]

   Once support for message interleaving as currently being discussed in
   [I-D.stewart-tsvwg-sctp-ndata] is available, it SHOULD be supported.

[CHH] Assuming we can rely on application-level fragmentation, I assume we would not need it. But, again, I am not familiar with the details of message interleaving. [/CHH]

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Wed, 05 Feb 2014 12:48:10 +1100

Hello Christer,

Part of the reason I suggested to use those sections of 
rtcweb-data-channel is so that we can make an educated decision about 
what we want to support for CLUE.
Please see below.

Regards, Christian

On 5/02/2014 1:29 AM, Christer Holmberg wrote:
>
> Hi,
>
> Christian earlier suggested that we could copy/paste section 6.1 from 
> the rtcweb-data-channel draft into our draft.
>
> I think we need to consider whether we really need the features listed 
> in that chapter (unless, of course, the usage of them is mandated in 
> order to be compatible with rtcweb).
>
[CNG] I agree. However if we say functions are not supported CLUE and 
RTCWEB says that they must be supported. What does that mean? e.g. We 
mandate the use of RTCweb data channel for CLUE. Therefore the rules of 
RTCweb data channel apply. Stream reset extension MUST be supported. 
However for CLUE we say it shouldn't be supported. The endpoint is not 
an RTCWEB endpoint it only supports CLUE over SCTP. So does it need to 
implement stream reset or not?

> [CHH] I may have misunderstood RFC6526, but I don’t think this is for 
> CLOSING channels. It’s for reseting the number sequence, which I think 
> is a different thing.
>
[CNG] I think the "resetting" is part of closing a channel. The 
resetting is done so that you can use the channel for another protocol. 
I'd say this has more of a general applicability An endpoint may want to 
close a channel and reuse it for CLUE or vice-versa.

> [CHH] It seems like this is only used for the reset extension. The 
> other features are related to multi-homing, which is not supported by 
> SCTPoDTLS to begin with. [/CHH]
>
[CNG] I guess to be precise they only want the support of clause 
4.2.7/RFC5061 "Supported Extensions Parameter"? Again this appears to be 
a generic function for SCTP.

> [CHH] I see no reason for support of partial reliability – eventhough 
> I have to admit I am not sure what it really means. In any case, my 
> suggestion is that CLUE always use “full” reliability. [/CHH]
>
[CNG] For the current Advertise/Configure procedures I also would see no 
support of partial reliability. However is CLUE evolves to somehow 
signal speaker changes in real time then this could come in handy. i.e. 
Bullet 1 clause 1.3/RFC3758. Rather than retransmission what is more 
important is that the most recent speaker message is processed. It would 
prevent a momentary audio/video switch.

As for limited retransmissions I'm not sure what the applicability would 
be to a CLUE channel?

> [CHH] Assuming we can rely on application-level fragmentation, I 
> assume we would not need it. But, again, I am not familiar with the 
> details of message interleaving. [/CHH]
>
[CNG] We currently don't have CLUE level fragmentation. Were you 
thinking of something else?

> Regards,
>
> Christer
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Feb 2014 07:40:03 +0000

Hi Christian,

> Part of the reason I suggested to use those sections of rtcweb-data-channel is so that we can make an educated decision about what we want to support for CLUE.

I could add the text, and indicate that the CLUE usage is FFS.

> [CNG] I agree. However if we say functions are not supported CLUE and RTCWEB says that they must be supported. What does 
> that mean? e.g. We mandate the use of RTCweb data channel for CLUE. Therefore the rules of RTCweb data channel apply. Stream reset extension MUST be supported. 
> However for CLUE we say it shouldn't be supported. The endpoint is not an RTCWEB endpoint it only supports CLUE over SCTP. So does it need to implement stream reset or not?

Those are things we need to clarify with RTCWEB.

>> [CHH] I may have misunderstood RFC6526, but I don't think this is for 
>> CLOSING channels. It's for reseting the number sequence, which I think 
>> is a different thing.
>>
> [CNG] I think the "resetting" is part of closing a channel. The resetting is done so that you can use the channel for another protocol. 
> I'd say this has more of a general applicability An endpoint may want to close a channel and reuse it for CLUE or vice-versa.

Sure. And, if someone wants to use it - fine. But, from a CLUE perspective we only have one protocol, so we don't need to mandate it.

> 4.2.7/RFC5061 "Supported Extensions Parameter"? Again this appears to be a generic function for SCTP.
>
>> [CHH] I see no reason for support of partial reliability - eventhough 
>> suggestion is that CLUE always use "full" reliability. [/CHH]
>>
> [CNG] For the current Advertise/Configure procedures I also would see no support of partial reliability. However is CLUE evolves to somehow signal speaker changes in real time then this could come in handy. i.e. 
> Bullet 1 clause 1.3/RFC3758. Rather than retransmission what is more important is that the most recent speaker message is processed. It would prevent a momentary audio/video switch.
>
> As for limited retransmissions I'm not sure what the applicability would be to a CLUE channel?

Also, don't think that you can't "switch" between reliable and non-reliable.

> [CNG] We currently don't have CLUE level fragmentation. Were you thinking of something else?

That is what PPID value 51 is used for. It basically indicates "More information is coming", so the receiver will have to buffer the received data. I don't think we need to add any extra to the CLUE protocol itself for this.

My understanding is that this was used in the demo shown at the virtual interim?

Regards,

Christer

---

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

Regarding fragmentation, my understanding is that there is an SCTP 
extension that handles the fragmentation at the SCTP layer, but that it 
is not yet ready for prime time. So for the webrtc data channel they 
have proposes to do application level fragmentation initially.

One purpose of fragmentation is to solve head of line blocking problems. 
That won't be a problem for clue *if* the clue channel is the only use 
of the association. But we should not assume that.

If we want to be compatible with rtcweb, then we need to be compatible 
with their fragmentation rules too.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Feb 2014 15:18:32 +0000

Hi,

>Regarding fragmentation, my understanding is that there is an SCTP extension that handles the fragmentation at the SCTP layer, but that 
>it is not yet ready for prime time. So for the webrtc data channel they have proposes to do application level fragmentation initially.
>
>That won't be a problem for clue *if* the clue channel is the only use of the association. But we should not assume that.
>
>If we want to be compatible with rtcweb, then we need to be compatible with their fragmentation rules too.

If the fragmentation can't be controlled by the JavaScript application, then I agree with you.

If the fragmentation can be controlled by the JavaScript application, then we can simply say not to use it.

Anyway, I have no problem to align with rtcweb, if we think it's feasible. Figuring such things out is part of the whole exercise :)

Regards,

Christer

On 2/5/14 2:40 AM, Christer Holmberg wrote:
>>> Christian earlier suggested that we could copy/paste section 6.1 
>>> from the rtcweb-data-channel draft into our draft.
>>>
>>> I think we need to consider whether we really need the features 
>>> listed in that chapter (unless, of course, the usage of them is 
>>> mandated in order to be compatible with rtcweb).
>>>
>> RTCWEB says that they must be supported. What does that mean? e.g. We mandate the use of RTCweb data channel for CLUE. Therefore the rules of RTCweb data channel apply. Stream reset extension MUST be supported.
>>> [CHH] I may have misunderstood RFC6526, but I don't think this is 
>>> for CLOSING channels. It's for reseting the number sequence, which I 
>>> think is a different thing.
>>>
>>> defined in [RFC6525], other features of [RFC5061] MUST NOT be used.
>>>
>>> other features are related to multi-homing, which is not supported 
>>> by SCTPoDTLS to begin with. [/CHH]
>>>
>>> [CHH] I see no reason for support of partial reliability - 
>>> eventhough I have to admit I am not sure what it really means. In 
>>> any case, my suggestion is that CLUE always use "full" reliability. 
>>> [/CHH]
>>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Feb 2014 15:36:00 +0000

Hi,

I found the following text in section 3.1. draft-stewart-tsvwg-sctp-ndata-03.txt:

	"A sender MUST NOT send a N-DATA chunk unless the peer has indicated
   	its support of the N-DATA chunk type within the Supported Extensions
   	Parameter as defined in [RFC5061]."

So, it seems like there will be an in-band negotiation regarding usage of interleaving.

Regards,

Christer

-----Original Message-----
From: clue [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 5. helmikuuta 2014 17:19
To: Paul Kyzivat; [email-masked]
Subject: Re: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require?

Hi,

>extension that handles the fragmentation at the SCTP layer, but that it is not yet ready for prime time. So for the webrtc data channel they have proposes to do application level fragmentation initially.
>

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Feb 2014 10:42:33 -0500

Unfortunately it seems that fragmentation is an issue we will not be 
able to ignore.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 5 Feb 2014 15:46:43 +0000

Hi,

My understanding is that basic fragmentation is already supported by vanilla SCTP.

Interleaving seems to be useful when one is sending VERY large messages. I guess the question is whether a CLUE message is a VERY large message :)

Regards,

Christer

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: 5. helmikuuta 2014 17:43
To: Christer Holmberg; [email-masked]
Subject: Re: [clue] CLUE Data Channel: SCTP Considerations - which ones does CLUE require?

Unfortunately it seems that fragmentation is an issue we will not be able to ignore.

	Thanks,
	Paul

On 2/5/14 10:36 AM, Christer Holmberg wrote:
> Anyway, I have no problem to align with rtcweb, if we think it's 
> feasible. Figuring such things out is part of the whole exercise :)
>
> Regards,
>
> Christer
>
>
>>> [CNG] I agree. However if we say functions are not supported CLUE 
>>> and RTCWEB says that they must be supported. What does that mean? e.g. We mandate the use of RTCweb data channel for CLUE. Therefore the rules of RTCweb data channel apply. Stream reset extension MUST be supported.
>>>> for CLOSING channels. It's for reseting the number sequence, which 
>>>> I think is a different thing.
>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Feb 2014 11:15:40 -0500

> My understanding is that basic fragmentation is already supported by vanilla SCTP.

I don't claim to be an expert.

> Interleaving seems to be useful when one is sending VERY large messages. I guess the question is whether a CLUE message is a VERY large message :)

It remains to be seen how big clue messages will be.
My *guess* is that even big advertisements aren't likely to be big 
enough to present head of line blocking issues, except perhaps if 
somebody is sending sensitive real time data on another channel.

But if rtcweb mandates fragmentation, and does it it browser code, but 
above SCTP, then we may need to be prepared to see it.

So we can't ignore it.

---

From: Christian Groves <[email-masked]>
Date: Thu, 06 Feb 2014 10:21:03 +1100

Hello Christer,

> Sure. And, if someone wants to use it - fine. But, from a CLUE perspective we only have one protocol, so we don't need to mandate it.
[CNG] CLUE may be initiated in a channel previously occupied by another 
application. 'Resetting' a closed CLUE channel may also be seen as a 
"clean/complete" closure of the CLUE channel.
> Also, don't think that you can't "switch" between reliable and non-reliable.
[CNG] I think the distinction is "reliable" and "less-reliable". Even in 
a "partial" mode the messages are delivered reliably expect when there's 
an indication "forget the previous messages" use this "one". So a sender 
could still deliver messages reliably in a "partial mode".

> That is what PPID value 51 is used for. It basically indicates "More information is coming", so the receiver will have to buffer the received data. I don't think we need to add any extra to the CLU…
[CNG] See other email about this PID based segmentation/reassembly.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 05 Feb 2014 18:41:58 -0500

On 2/5/14 6:21 PM, Christian Groves wrote:
>>> RTCWEB says that they must be supported. What does
>>> that mean? e.g. We mandate the use of RTCweb data channel for CLUE.
>>> Therefore the rules of RTCweb data channel apply. Stream reset
>>> extension MUST be supported.
>>> However for CLUE we say it shouldn't be supported. The endpoint is
>>> not an RTCWEB endpoint it only supports CLUE over SCTP. So does it
>>> need to implement stream reset or not?
>>> I'd say this has more of a general applicability An endpoint may want
>>> to close a channel and reuse it for CLUE or vice-versa.
>> Sure. And, if someone wants to use it - fine. But, from a CLUE
>> perspective we only have one protocol, so we don't need to mandate it.

I think we have talked about the possibility of signaling "I don't want 
to do CLUE any more on this call".

Given the possibility of using some data channels (sctp streams) for 
non-clue purposes, we can't require removing the SCTP association to 
indicate this.

ISTM that closing the channel, by resetting the corresponding streams, 
could be part of that. Perhaps accompanied by a Configure that doesn't 
request any encodings. (We might want to use a channel close for error 
recovery too.)

And once you have said "I don't want to do CLUE any more", then later 
you may change your mind and say "now I want to do CLUE again". That 
*could* be indicated by sending an OPEN for the CLUE protocol again. And 
this time it might be on a different channel.

But (if we agree not to use one channel for both provider and consumer) 
I don't see any non-error cases where we would have two concurrent clue 
channels.

	Thanks,
	Paul