Subject: [clue] comments on draft-kyzivat-clue-signaling-02

From: "Charles Eckel (eckelcu)" <[email-masked]>
Date: Tue, 19 Mar 2013 17:30:46 +0000

Hi Paul,

I mentioned some of these at the mic, at which time I agreed  to follow up on them via the list. 

1) Section 3.1.3.
It seems natural and appropriate to negotiate the CLUE version in SDP where you negotiate the CLUE channel. This is essentially what we have proposed to do for BFCPBIS as well.

2) Section 3.3.2
The section is titled "Piggybacking ACK on Requests", yet it contains the following bullet:
  o  If a valid message is received and there is no need to immediately
      send another message, then a NO-OP message is sent to acknowledge
      the received message.  But a NO-OP message is never sent in
      response to a NO-OP message.
It seems to me that this results in it being essentially the same as the explicit ACK method in section 3.3.1. If we were to omit this bullet, then I see some benefit in the Piggybacking method. Do you see any problems that necessitate a NO-OP?

3) Section 3.4.1 reads as follows:

      If the change must be outside the range of what was advertised,
      then the provider must cease transmitting the capture encoding.
      It then must send a new ADVERTISEMENT reflecting what it is now
      capable of delivering.

I assume congestion resulting in tmmbr would NOT require a new advertisement. Is that consistent with your thinking on this?

4) Section 3.4.2
Handling loss of CLUE state information by establishing a new CLUE session seems simply and sufficient. 

5) Section 4 and 5 seem to be good places to insert the information in draft-hansen-clue-sdp-interaction.

Cheers,
Charles

---

From: Christian Groves <[email-masked]>
Date: Mon, 25 Mar 2013 14:56:56 +1100

Hello,

Please see my comments below.

> It seems natural and appropriate to negotiate the CLUE version in SDP where you negotiate the CLUE channel. This is essentially what we have proposed to do for BFCPBIS as well.
[CNG] I would agree but I think you'd also want to carry the indication 
of the agreed version in CLUE so the endpoints know exactly what version 
is being used.
> Handling loss of CLUE state information by establishing a new CLUE session seems simply and sufficient.
[CNG] This would require a new O/A and re-establishment of the transport 
session. This would require synchronisation with ongoing RTP streams as 
they most likely will be associated with particular capture IDs etc.
If there's nothing wrong with the transport the Consumer could as easily 
send a Configure message with a code indicating "please send an updated 
advertisement".
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Mar 2013 22:24:09 +0800

Some followup inline.

On 3/25/13 11:56 AM, Christian Groves wrote:

>> 1) Section 3.1.3.
>> It seems natural and appropriate to negotiate the CLUE version in SDP
>> where you negotiate the CLUE channel. This is essentially what we have
>> proposed to do for BFCPBIS as well.

If we negotiate it in SDP but also signal it in the clue channel itself, 
then we introduce the possibility of a new class of errors when these 
values are inconsistent. That isn't a fatal flaw, but it is worth 
considering.

If it is to be signaled in the clue channel, then why not 
verify/negotiate it there as well, rather than in SDP?

A downside of that is that the sip session may get set up before 
discovering that the two sides don't support a common clue version. But 
that is only a problem if it then leads to dropping the call. I think in 
reality that would lead to treating it as a "legacy" call.

I guess an advantage to having the version in SDP is that it might be 
used to make a routing decision, to an endpoint that supports that 
version, rather than a different endpoint that doesn't. But I find this 
rather far fetched.

So, ISTM that if we are to convey the version in the clue channel we 
might as well do the version negotiation there too. That would keep 
things quite modular.

But I can be convinced otherwise.

> session.

This may require some discussion and eventually documentation.
Presumably a new O/A will be required if any part of the SCTP 
association addresses must be changed. I don't know if there is any 
point in attempting to reestablish the association using the same 
address info.

(IIUC, SCTP supports multiple, alternative, addresses for each end of 
the association, and even adding new ones in band in the protocol. But 
the SCTP over DTLS mapping takes that away. So presumably we can ignore it.)

If a new O/A is done to "fix" this, must any special behavior be called 
out to ensure the exact same 5-tuple isn't attempted again? There may be 
no alternative to the local address, though a new port may be possible. 
If ICE is in use, then perhaps candidate gathering could be restarted.

> This would require synchronisation with ongoing RTP streams as

I guess this depends on some local implementation issues that we have no 
business specifying. If capture IDs are assigned in some deterministic 
way then maybe they will be stable across a reset. But if they are 
dynamically assigned then they probably won't be.

So does this mean that RTP should cease, or revert to "legacy mode", 
until the clue channel is renegotiated? Or can RTP simply continue as it 
was until a new advertisement/config demands that it change?

> send a Configure message with a code indicating "please send an updated

Maybe.

IMO this calls for some state machine work that can be used to identify 
significant states. Then behavior can be linked to the state.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Tue, 26 Mar 2013 11:07:33 +1100

Hello Paul,

Please see see below.

Regards, Christian

On 26/03/2013 1:24 AM, Paul Kyzivat wrote:
> If we negotiate it in SDP but also signal it in the clue channel 
> itself, then we introduce the possibility of a new class of errors 
> when these values are inconsistent. That isn't a fatal flaw, but it is 
> worth considering.
[CNG] I don't think it a flaw at all. If either case if you get an 
information element that is not relevant for the version supported its 
an error.
> verify/negotiate it there as well, rather than in SDP?
[CNG] It could be done but its potentially another round trip.
> discovering that the two sides don't support a common clue version. 
> But that is only a problem if it then leads to dropping the call. I 
> think in reality that would lead to treating it as a "legacy" call.
[CNG] Yes
> version, rather than a different endpoint that doesn't. But I find 
> this rather far fetched.
[CNG] The advantage is what is stated above. You can figure out the 
version before establishing another data connection.
> point in attempting to reestablish the association using the same 
[CNG] I think it depends on the class of error as to whether the same 5 
tuple is used. If there's a network problem probably not, if the 
endpoint SW has hung that tuple maybe its OK to restart it.
> If a new O/A is done to "fix" this, must any special behavior be 
> called out to ensure the exact same 5-tuple isn't attempted again? 
> There may be no alternative to the local address, though a new port 
> may be possible. If ICE is in use, then perhaps candidate gathering 
> could be restarted.
>
> I guess this depends on some local implementation issues that we have 
> no business specifying. If capture IDs are assigned in some 
> deterministic way then maybe they will be stable across a reset. But 
> if they are dynamically assigned then they probably won't be.
[CNG] I don't think we need to specify CaptureID allocation. Rather to 
indicate what happens to existing captureIDs (particularly those 
assigned to an RTCP stream) when a CLUE association is removed (and 
possibly replaced).
> until the clue channel is renegotiated? Or can RTP simply continue as 
> it was until a new advertisement/config demands that it change?
[CNG] That's the question that needs consideration. We need to specify 
some common behaviour here. In some respects we need to consider CLUE 
captureID etc lifetime. I could envisage that a CLUE association is 
established to setup a conference and then removed once the conference 
has been established. So it seems that to continue RTP with whatever 
CLUE Ids that were negotiated before would be OK behaviour. However if a 
new CLUE association is started it would seem to me that any assumptions 
about state should be reset.
> IMO this calls for some state machine work that can be used to 
> identify significant states. Then behavior can be linked to the state.
[CNG] I'm not sure what you mean here? With the framework there's an 
assumption that the consumer maintains its configuration wrt to CLUE. If 
this changes or is lost then the consumer should be able to request an 
updated Advertisement.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 27 Mar 2013 00:18:07 +0800

More comments inline

> [CNG] It could be done but its potentially another round trip.

Maybe, depending on the details of how it is done.
I agree that doing it in SDP (or in SIP) will guarantee the minimum time 
to get it worked out.

I'm ok with doing it in SDP (or SIP) as long as we are satisfied with a 
negotiation that fits well in SDP O/A.

Perhaps we should be talking about versioning the overall relationship 
between the two endpoints - encompassing all the signaling and 
coordinated clue-mandated behavior, whether in SIP, SDP, over the clue 
channel, in RTP, etc. We then might, or might not, want to separately 
negotiate a finer level of versioning of the clue channel as a 
sub-protocol of that.

> assigned to an RTCP stream) when a CLUE association is removed (and

Yes.

> captureID etc lifetime.

I have been assuming the lifetime is "until changed via a new 
advertisement". I think that is fine as long as the clue channel is 
present and operational. But I agree we have more to specify in the case 
where the clue channel is closed or becomes non-functional.

> I could envisage that a CLUE association is
> has been established.

I had not considered that. It seems like a bad idea to me. My thinking 
was that removing the clue channel (at least explicitly) should cause 
the session to revert to legacy mode. (If the clue channel *fails* then 
one may want to assume things remain as they were for a time while 
trying to reestablish the channel.)

ISTM that this is reasonable because the cost of maintaining the channel 
is low, and is really needed in case something happens that requires 
further signaling. And reverting to legacy mode is also a behavior that 
is valuable to have available. (E.g. it can be needed in the case where 
a the peer transfers the call to an endpoint that is clueless. This 
could happen when departing a TP room and continuing the call on a cell 
phone.)

> So it seems that to continue RTP with whatever

As I mentioned above, if the old association *failed* I can see working 
this way. Perhaps just treat the new association and channel as a 
continuation of the old one. The change would occur with new 
advertisements are exchanged over the new channel.

But if the old association is gracefully shut down then perhaps revert 
to legacy mode. An alternative to that would be to have *explicit* 
signaling to revert to legacy mode, after which one could tear down the 
association.

Another issue is who is responsible for establishing a new association 
if the old one fails, and when. If this isn't spelled out, then one side 
may explicitly close it and expect it to stay closed, while the other 
side decides to request a new one.

> this changes or is lost then the consumer should be able to request an

I'm thinking that an endpoint "forgetting" the peer's advertisement is 
an error state. Then the recovery from that error state is to request, 
and then receive, another advertisement. This state machine would 
include the startup state (when both sides need to send an 
advertisement), a state where an advertisement has been received and a 
decision to send a config must be made, a normal (steady) state when 
nothing need be exchanged, perhaps a "legacy mode" state, and perhaps 
some others.

It is unclear to me right now whether there should be separate state 
machines for providers and consumers (where most endpoints would have 
one of each), or a single state machine that encompasses both provider 
and consumer behavior. If it is done with separate state machines, then 
they probably need to be coupled, at least at session startup, to 
minimize glare conditions.

Just "describing" this is inadequate. I need to actually propose 
something explicit here.

	Thanks,
	Paul