Subject: [clue] Data channel impact on CLUE state

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Jan 2014 03:30:17 +0000

Hi,

One of the things, related to the data channel used for the CLUE protocol, is what impact the data channel has on the CLUE session (if there is such thing) itself.

I have identified the following cases:

CASE #1: Data channel removed without signaling:

If the data channel for some reason disappears without signaling, it does NOT impact the CLUE session. Everything goes on as before, based on
previous CLUE- and SDP exchanges. Obviously, the data channel should re-established asap.

CASE #2: Data channel removed by setting port to zero:

If the data channel is explicitly removed, by setting the port value is set to zero, but the media m- lines are still non-zero, media can still be exchanged, but my
suggestion is that any previously negotiated CLUE information (capture information, spatial information) etc is removed at that point. So, obviously this should not happen
unless one really wants to stop using CLUE.

CASE #3: Data channel removed on SCTP level:

                             Same as for CASE #2: If someone explicitly removes the data channel (the SCTP connection MAY still be kept for other purpose), it is an indication that the CLUE protocol is no more used, and any associated CLUE state is removed.

CASE #4: Data channel set inactive:

                             Same as for CASE #1: This use-case is probably going to be rare, but there MAY e.g. be some transfer cases where it could occur.

Regards,

Christer

---

From: Christian Groves <[email-masked]>
Date: Fri, 24 Jan 2014 16:33:27 +1100

Hello Christer,

Please see below.

Regards, Christian

On 24/01/2014 2:30 PM, Christer Holmberg wrote:
>
> Hi,
>
> One of the things, related to the data channel used for the CLUE 
> protocol, is what impact the data channel has on the CLUE session (if 
> there is such thing) itself.
>
> *CASE #1: Data channel removed without signaling:*
>
> If the data channel for some reason disappears without signaling, it 
> does NOT impact the CLUE session. Everything goes on as before, based on
>
[CNG] Can you be a little more precise than "everything goes on as 
before"? I assume the media continues to flow. However I guess the 
endpoints aren't going to try to update the CLUE session by issuing new 
Adverts / Configs? If it doesn't establish after a timeout should the 
CLUE session be removed formally by SDP signalling? etc.
>
> *CASE #2: Data channel removed by setting port to zero:*
>
> If the data channel is explicitly removed, by setting the port value 
> is set to zero, but the media m- lines are still non-zero, media can 
> still be exchanged, but my
>
> suggestion is that any previously negotiated CLUE information (capture 
> information, spatial information) etc is removed at that point. So, 
> obviously this should not happen
>
> *CASE #3: Data channel removed on SCTP level:*
>
> Same as for CASE #2: If someone explicitly removes the data channel 
> (the SCTP connection MAY still be kept for other purpose), it is an 
> indication that the CLUE protocol is no more used, and any associated 
> CLUE state is removed.
>
> *CASE #4: Data channel set inactive:*
>
> Same as for CASE #1: This use-case is probably going to be rare, but 
> there MAY e.g. be some transfer cases where it could occur.
>
[CNG] Do you mean setting a=inactive? I assume this means that if the 
endpoint tries to send a Advert/Config it won't actually be transmitted 
across the channel. Even if the media stays up.
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Jan 2014 05:44:21 +0000

Hi,

> [CNG] Can you be a little more precise than "everything goes on as before"? I assume the media continues to flow.

Correct.

> However I guess the endpoints aren't going to try to update the CLUE session by issuing new Adverts / Configs?

Correct.

> If it doesn't establish after a timeout should the CLUE session be removed formally by SDP signalling? etc.

That was going to be my next question, but: Yes :)

> [CNG] Do you mean setting a=inactive?

Correct.

> I assume this means that if the endpoint tries to send a Advert/Config it won't actually be transmitted across the channel. Even if the media stays up.

Well, the message might be transmitted if sent, but an endpoint should not try to send a message to begin with in such case.

The same applies to the media channels, so it would not be a CLUE specific handling of "inactive". The important thing is that it would not affect the CLUE session as such.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Jan 2014 00:51:28 -0500

> previous CLUE- and SDP exchanges. Obviously, the data channel should

Do you mean the channel, or the SCTP association?

This is an error case, so the actions have to do with trying to fix the 
error and coping in the meantime.

When digging into this, exactly what is meant by "*removed* without 
signaling"? Since you are distinguishing this from case #3, does this 
imply that the SCTP association is ok, but there has been some sort of 
*channel* level error? (E.g., loss of a packet on the channel.) Or do 
you mean some sort of SCTP error that can't be attributed to a 
particular channel?

Then there are cases where the channel is ok at the packet level, but 
there are problems above that. For instance, a packet in the channel was 
sent with the SCTP packet attributes inconsistent with what the CLUE 
protocol calls for. (I'm not sure that can happen.)

And then there are actual clue protocol errors (e.g. bad syntax of the 
packet content). But they probably don't belong in this section.

> If the data channel is explicitly removed, by setting the port value is
> set to zero, but the media m- lines are still non-zero, media can still
> be exchanged, but my
>

You mean that the SCTP association is removed. So of course the specific 
channel(s) used for CLUE also go away.

ISTM we should treat this in a layered fashion. Deal with this at one 
level as the channel going away. Deal separately with the association 
going away. (If we are in a state where we don't want to reestablish the 
channel, then we don't mind that the association is down. But if we are 
in a state where we are supposed to be reestablishing the channel, then 
we must first reestablish the association.)

IOW, I suspect we will need one state machine for the SCTP association, 
and then, for certain SCTP states, a sub-state-machine for each channel 
that is being used by CLUE.

>                               Same as for CASE #2: If someone explicitly
> removes the data channel (the SCTP connection MAY still be kept for
> other purpose), it is an indication that the CLUE protocol is no more
> used, and any associated CLUE state is removed.

Again I think this maybe should be deferred to the protocol state 
machines. Especially if we decide to have separate state machines for 
each direction, then one going away may simply mean that *direction* 
stops, while the other direction continues.

>                               Same as for CASE #1: This use-case is
> probably going to be rare, but there MAY e.g. be some transfer cases
> where it could occur.

I don't know if this is even well defined for SCTP. We should probably 
bring this up in mmusic wrt the SDP for SCTP. (And what about sendonly 
and recvonly?)

If it is well defined, then it has the effect of temporarily blocking 
the creation or destruction of channels, and the transmission of 
packets. Perhaps this should merely be reflected as events in the clue 
protocol state machine. (An error when attempting to send.)

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 24 Jan 2014 06:07:56 +0000

Hi,

>> does NOT impact the CLUE session. Everything goes on as before, based 
>> on previous CLUE- and SDP exchanges. Obviously, the data channel should 
>> re-established asap.
>

I said the channel, but I should have said the SCTP association. See more below.

> This is an error case, so the actions have to do with trying to fix the error and coping in the meantime.

Correct.

> When digging into this, exactly what is meant by "*removed* without signaling"? Since you are distinguishing this from case #3, does this imply that the SCTP association is ok, but there has been some sort of
> *channel* level error? (E.g., loss of a packet on the channel.) Or do you mean some sort of SCTP error that can't be attributed to a particular channel?

IF there are SCTP errors that can affect a particular channel, then yes.

But, I was thinking more about loss of e.g. network bearer or resources.

> Then there are cases where the channel is ok at the packet level, but there are problems above that. For instance, a packet in the channel was sent with the SCTP packet attributes inconsistent with what the CLUE protocol calls for. (I'm not sure that can happen.)

We for sure have to go into the details. 

But, at the end of the day, what I am suggesting is that the termination of a CLUE session requires signaling (e.g. Offer/Answer) which explicitly removes the CLUE channel.

> And then there are actual clue protocol errors (e.g. bad syntax of the packet content). But they probably don't belong in this section.

Correct. 

Of course, we may specify that certain protocol errors (or non-errors) trigger an explicit removal of the CLUE channel, but that is more related to the CLUE protocol details.

Correct. 

> ISTM we should treat this in a layered fashion. Deal with this at one level as the channel going away. Deal separately with the association going 
> away. (If we are in a state where we don't want to reestablish the channel, then we don't mind that the association is down. But if we are in a state 
> where we are supposed to be reestablishing the channel, then we must first reestablish the association.)
>
> IOW, I suspect we will need one state machine for the SCTP association, and then, for certain SCTP states, a sub-state-machine for each channel that is being used by CLUE.

Perhaps. But, I hope we can manage to not complicate things too much. That will only lead to different entities having different understanding of the CLUE session.

>>                               Same as for CASE #2: If someone 
>> explicitly removes the data channel (the SCTP connection MAY still be 
>> kept for other purpose), it is an indication that the CLUE protocol is 
>> no more used, and any associated CLUE state is removed.
>
> Again I think this maybe should be deferred to the protocol state machines. Especially if we decide to have separate state machines for each direction, then one going away may simply mean that *direction* stops, while the other direction continues.
>
> I don't know if this is even well defined for SCTP. We should probably bring this up in mmusic wrt the SDP for SCTP. (And what about sendonly and recvonly?)
>
> If it is well defined, then it has the effect of temporarily blocking the creation or destruction of channels, and the transmission of packets. Perhaps this should merely be reflected as events in the clue protocol state machine. (An error when attempting to send.)

Yes.

Note, that I do NOT intend to cover all this in my data channel presentation. I want us to first focus on the basics (e.g. how the data channel is created, whether we re-use RTCWEB stuff etc), and once we agree on that we take the next step :)

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Jan 2014 11:27:31 -0500

> But, I was thinking more about loss of e.g. network bearer or resources.

I guess somehow we may need to classify the different sorts of errors 
that can be recognized. What an implementation can do depends on what is 
exposed via the api to the stack. Its tricky because we don't want to 
get to the stack details, but we need to make some distinctions.

I'm thinking there may be association-level errors, sctp stream level 
errors, perhaps datachannel errors, and clue protocol errors. These are 
layered. (And if we go deeper, there may be UDP errors and DTLS errors. 
But I don't think we need to concern ourselves with these because we can 
treat them as sctp association errors.)

> But, at the end of the day, what I am suggesting is that the termination of a CLUE session requires signaling (e.g. Offer/Answer) which explicitly removes the CLUE channel.

I think I agree:
- it takes explicit signaling to establish the clue channel
- after that, problems with the clue channel are treated as
   *errors* until there is explicit signaling that we don't
   want the clue channel any longer.

> Perhaps. But, I hope we can manage to not complicate things too much. That will only lead to different entities having different understanding of the CLUE session.

If things are simple enough, then we can just use some words without a 
state machine. But the advantage of state machines is that they are very 
precise, which is hard to accomplish with words.

> Note, that I do NOT intend to cover all this in my data channel presentation. I want us to first focus on the basics (e.g. how the data channel is created, whether we re-use RTCWEB stuff etc), and…

We need to start somewhere, and then elaborate until we have enough.

	Thanks,
	Paul