Subject: [clue] I-D Action: draft-ietf-clue-protocol-02.txt

From: [email-masked]
Date: Fri, 24 Oct 2014 06:10:07 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the ControLling mUltiple streams for tElepresence Working Group of the IETF.

        Title           : CLUE protocol
        Authors         : Roberta Presta
                          Simon Pietro Romano
	Filename        : draft-ietf-clue-protocol-02.txt
	Pages           : 59
	Date            : 2014-10-24

Abstract:
   The CLUE protocol is an application protocol conceived for the
   description and negotiation of a CLUE telepresence session.  The
   design of the CLUE protocol takes into account the requirements and
   the framework defined, respectively, in [I-D.ietf-clue-framework] and
   [I-D.ietf-clue-telepresence-requirements].  The companion document
   [I-D.ietf-clue-signaling] delves into CLUE signaling details, as well
   as on the SIP/SDP session establishment phase.  CLUE messages flow
   upon the CLUE data channel, based on reliable and ordered SCTP over
   DTLS transport, as described in [I-D.ietf-clue-datachannel].  Message
   details, together with the behavior of CLUE Participants acting as
   Media Providers and/or Media Consumers, are herein discussed.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-clue-protocol/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-clue-protocol-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-clue-protocol-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Roberta Presta <[email-masked]>
Date: Fri, 24 Oct 2014 15:42:26 +0200

Dear all,
we have just uploaded the new version of the protocol document to be 
discussed in the next call.
In the following the diff with version 01.
Best regards,

Roberta

    o  The diff mechanism for the ADV message has been introduced.

    o  READV and READV RESPONSE message have been both removed.

    o  The state machines have been deeply reviewed and changed.

    o  References: references have been updated and splitted into
       Informative references and Normative references as in framework
       v17.

    o  Schema: <globalSceneEntries> changed in <globalViews>,
       <participants> in <people>

    o  Terminology: many definitions added. Response codes updated.

Il 24/10/2014 15:10, [email-masked] ha scritto:
> _______________________________________________
> clue mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/clue
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Oct 2014 16:17:53 -0400

I have tried to go through the key changes in the protocol document. 
Here are the things I noted:

The new definition of Advertisement now has a choice of the full adv, or 
a partial adv. The partial adv starts out directly with add/remove/... I 
see nothing that explicitly indicates the body that is being modified. 
Looking at the example, the xpath expression references something like 
"/advertisement/people", but that could apply to *any* version of the 
advertisement. I guess the intent is that it reference the "latest" one. 
But it seems like it would be better to have some identifier that makes 
clear what is to be modified. For instance, a reference to the sequence 
number of the advertisement being updated.

Why has READV been *removed*? Has something changed so that we don't 
need it? (I was advocating for renaming it, not removing it.)

* Section 4.7:

Regarding response code numbering: is the goal to follow SIP or HTTP 
numbering philosophies? Why are some errors given 3xx codes and others 
4xx codes?

* Section 6:

I have a number of comments on this section and subsections. I'll try to 
be as specific as I can, but it is hard to discuss potential changes, 
because everything is interconnected. It would be best if we could have 
an interactive whiteboard session on this. But I doubt that is in the cards.

    ... If the CP receives a further
    OPTIONS/OPTIONS RESPONSE message, it MUST ignore the message and stay
    in the ACTIVE state.

Is this really the best thing to do in this case? Ignoring messages, 
without even responding, can't come to any good end. I would think that 
either an error response should be sent to the message, or else the clue 
session should be terminated.

One way to handle this would be to view this as a outer state machine 
that does the sending/receiving of messages and demuxing them among 
OPTIONS, MP, and MC state machines. So OPTIONS messages and their 
responses always go to the OPTIONS state machine, and other messages to 
their respective state machines. (Messages that are not identifiable as 
requests or responses destined for any of the sub-state-machines would 
result is an error that closes the channel.)

Initially, the OPTIONS state machine processes OPTIONS messages, while 
the MP and MC machines consider messages to them errors. After options 
processing is completed, OPTIONS messages still go to the OPTIONS state 
machine, but it treats them as errors, sending a suitable error 
response. Initially the MP and MC state machines treat messages to them 
as errors. After the options processing is completed, one or both of 
them enter a state where they process their corresponding messages.

* Section 6.1:

A general observation: I think it is unclear how the timing of the 
arrival of messages affects this state machine. It seems unnecessarily 
complex to deal with a message arriving at any time, yet it seems 
impossible to avoid that possibility. The best solution I can think of 
is that there should be a message queue associated with the state 
machine. When the outer state machine identifies a message that should 
be processed by this state machine then that message can enter the 
queue. Then this state machine can process messages from that queue at 
convenient times. Those times correspond to the "wait for X" states, and 
the ESTABLISHED state. When in those states, you are really waiting for 
a message, and then must branch on what sort of message it is.

What does "retry expired"/"retry not expired" mean, and how does it 
relate to "timeout". (Not just here - also in subsequent sections.) I 
have the impression from past discussions that you intend that there be 
some time limit or limits to be applied to the receipt of certain 
expected messages, and also that there be some limited number of retries 
sending messages when an expected reply has not been received. But I 
don't find even that much detail in the text, and more than that is 
needed to make this be a sufficient specification. (There is a *little* 
bit about retry threshold in 6.2.) Without more detail I can't even 
guess whether that will work adequately.

Next, consider

    ... CONF+ACK messages referring to out-of-date ADVs should be
    ignored, i.e., they do not trigger any state transition.

Again, ignoring messages seems like a very bad idea. It leads to hangs. 
I think there must be a response to this, indicating that it has failed. 
And perhaps also send a new ADV and hope the consumer gets things 
straightened out after that.

* Section 6.2:

(Some of the general issues I raised above for 6.1 apply here too.)

    An MC in the WAIT FOR ADV state is waiting for an ADV coming from the
    MP.  If the ADV arrives ("ADV received"), the MC reaches the
    PROCESSING ADV state.  Otherwise, the MC is stuck in the WAIT FOR ADV
    state.

Suppose what arrives is some message other than an ADV. (I guess the 
only thing that could be here is a CONF response.) If something odd like 
that happens then I think it must not be just ignored. But you can't 
send a response to a response. We may need another message to report bad 
things. And/or maybe the channel should be torn down.

    ... If
    the NACK retry expires ("retry expired"), the MC moves to the MC
    TERMINATED state.

This is a pretty serious state. I think CLUE is still enabled, but the 
MC is terminated. In that state, what happens to incoming messages? 
(ADVs) If they aren't responded to then bad things will happen. I think 
two things are needed: (1) a NAK must still be sent, with indication 
that this is a fatal error for the MC; (2) in the TERMINATED state 
messages must still be accepted, with error responses to requests. 
Ideally, if the MC goes to the TERMINATED state then we want the MP at 
the other end to also go to that state.

    When the SDP information arrives, from the ADV RECEIVED or the ADV
    ACKED state the MC switches to the READY TO CONF state.  When the
    CONF request is ready, the MC sends it and moves to the TRYING state.
    If the ADV has not yet been sent, the MC can piggyback the ACK
    message inside the CONF request.
...
    When the MC is in the SDP O/A state, the telepresence session
    configuration has been set up at the CLUE application level according
    to the MC's preferences.  Both the MP and the MC have agreed on (and
    are aware of) the media streams to be exchanged within the call.  In
    this state, the MC waits for the SDP offer coming from the MP.  As
    soon as it arrives, the MC replies with an SDP answer.

I wonder if the first of these paragraphs is in the wrong place, or is 
simply old info no longer intended to be here. For instance, I see no 
ADV RECEIVED or ADV ACKED states. And it seems in an odd place in the 
flow of text.

In any case, waiting for SDP may present similar issues to waiting for a 
message. (SDP arrival is far too unsynchronized from the state machine 
to depend on it arriving exactly when you want it.) So it may be that 
the state machine needs a queue for this that can be queried from the 
state that cares. ISTM more consideration is needed of the impact of SDP 
changes on this state machine.

Regarding initiation of an O/A - it certainly can be the case that a new 
O/A is not needed. I see no provision for that possibility.

Perhaps O/A should be handled with a separate state machine - loosely 
coupled (by events) to both MC and MP machines. (So that a newly 
accepted CONF triggers an event to the O/A state machine, causing it to 
analyze the most recent configuration of both MC and MP, and decide if a 
new offer should be sent.) Considering that both ends are likely to have 
both an MC and an MP, it seems like it might be tricky to decide who 
should send a new offer.

* Section 11.4: DNS Registrations

Why do we need any DNS registrations???

We want a feature tag and an SDP grouping tag, but the signaling draft 
deals with those.

* I didn't yet review the examples.

	Thanks,
	Paul

---

From: Roberta Presta <[email-masked]>
Date: Tue, 28 Oct 2014 13:55:51 +0100

Dear Paul,
thank you for your review.
We start to answer to your comments below.
We will discuss in more detail some of your observations during the call 
and/or in following emails.

Roberta

Il 27/10/2014 21:17, Paul Kyzivat ha scritto:
> The new definition of Advertisement now has a choice of the full adv, 
> or a partial adv. The partial adv starts out directly with 
> add/remove/... I see nothing that explicitly indicates the body that 
> is being modified. Looking at the example, the xpath expression 
> references something like "/advertisement/people", but that could 
> apply to *any* version of the advertisement. I guess the intent is 
> that it reference the "latest" one. But it seems like it would be 
> better to have some identifier that makes clear what is to be 
> modified. For instance, a reference to the sequence number of the 
> advertisement being updated.
The intention was to update with a partial ADV just the latest 
sent-and-acked ADV, and not any previously sent ADV.
This is text from the current version:
"When an ADV sent from the MP to the MC has been ACK-ed by the MC, the 
MP can decide to send the next ADV in a diff format with respect to  the 
previously sent ADV."
No problem with adding a field specifying the number of the ADV to refer 
to, but it conveys a "redundant" information, since the ADV to refer to 
is always the latest sent-and-acked.
If the sequence number is not the one of the latest sent-and-acked ADV, 
the MC should NACK the partial ADV with an ad-hoc response code.
> need it? (I was advocating for renaming it, not removing it.)
While reviewing the state machines, we found the message redundant in 
each case where in the past we  thought it could be useful. It is one of 
the topic of the today's discussion.
> numbering philosophies? Why are some errors given 3xx codes and others 
Response codes are one of the listed open issues. They need to be 
improved to cover  the possible situations. In the current version of 
the document, they do not follow any of the mentionend philosophies.
> * Section 6:
>
> I have a number of comments on this section and subsections. I'll try 
> to be as specific as I can, but it is hard to discuss potential 
> changes, because everything is interconnected. It would be best if we 
> could have an interactive whiteboard session on this. But I doubt that 
> is in the cards.
>
> without even responding, can't come to any good end. I would think 
> that either an error response should be sent to the message, or else 
> the clue session should be terminated.

The reason why we decided to ignore these messages while the CP is in 
the active state  is that we stated the initiation phase is done exactly 
once in each CLUE session.
When this phase is over (successfully concluded) , the CP moves in the 
ACTIVE state.
There is no need to issue again OPTIONS/OPTIONS RESPONSE messages since 
the session is successfully negotiated in terms of the version of the 
protocol and the options to be used. If, for any reason, a new version & 
options negotiation needs to be triggered, than the application level 
should end the current CLUE session (CP moves to TERMINATED) and should 
start a new one.

> responses always go to the OPTIONS state machine, and other messages 
> to their respective state machines. (Messages that are not 
> identifiable as requests or responses destined for any of the 
> sub-state-machines would result is an error that closes the channel.)
>
> processing is completed, OPTIONS messages still go to the OPTIONS 
> state machine, but it treats them as errors, sending a suitable error 
> response. Initially the MP and MC state machines treat messages to 
> them as errors. After the options processing is completed, one or both 
> of them enter a state where they process their corresponding messages.
>
> * Section 6.1:
>
> convenient times. Those times correspond to the "wait for X" states, 
> and the ESTABLISHED state. When in those states, you are really 
> waiting for a message, and then must branch on what sort of message it 
> is.
>
In general, we adopted the philosophy of keeping it simple and working. 
We are quite confident that we avoid hang situations with the proposed 
solution. We listed just the events (typically, message sent/received) 
triggering state transitions and we do not diagram/consider other events 
that should not be possible if implementing correctly the proposed state 
machines.

> have the impression from past discussions that you intend that there 
> be some time limit or limits to be applied to the receipt of certain 
> expected messages, and also that there be some limited number of 
> retries sending messages when an expected reply has not been received. 
> But I don't find even that much detail in the text, and more than that 
> is needed to make this be a sufficient specification. (There is a 
> *little* bit about retry threshold in 6.2.) Without more detail I 
> can't even guess whether that will work adequately.
>
We agree that more text is needed to explain the timeout and retry 
mechanism. We plan to add it asap.
> Again, ignoring messages seems like a very bad idea. It leads to 
> hangs. I think there must be a response to this, indicating that it 
> has failed. And perhaps also send a new ADV and hope the consumer gets 
> things straightened out after that.
>
The case you present here will be clarified with a sample call flow 
which is coherent with the current specification of the state machines.
The rest of your review will be considered in following emails /disussion.
Thank you again,

Roberta and Simon

> only thing that could be here is a CONF response.) If something odd 
> like that happens then I think it must not be just ignored. But you 
> can't send a response to a response. We may need another message to 
> report bad things. And/or maybe the channel should be torn down.
>
>    ... If
> (ADVs) If they aren't responded to then bad things will happen. I 
> think two things are needed: (1) a NAK must still be sent, with 
> indication that this is a fatal error for the MC; (2) in the 
> TERMINATED state messages must still be accepted, with error responses 
> to requests. Ideally, if the MC goes to the TERMINATED state then we 
> want the MP at the other end to also go to that state.
>
> In any case, waiting for SDP may present similar issues to waiting for 
> a message. (SDP arrival is far too unsynchronized from the state 
> machine to depend on it arriving exactly when you want it.) So it may 
> be that the state machine needs a queue for this that can be queried 
> from the state that cares. ISTM more consideration is needed of the 
> impact of SDP changes on this state machine.
>
> Regarding initiation of an O/A - it certainly can be the case that a 
> new O/A is not needed. I see no provision for that possibility.
>
> accepted CONF triggers an event to the O/A state machine, causing it 
> to analyze the most recent configuration of both MC and MP, and decide 
> if a new offer should be sent.) Considering that both ends are likely 
> to have both an MC and an MP, it seems like it might be tricky to 
> decide who should send a new offer.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Oct 2014 11:16:44 -0400

Hi Roberta,

More discussion inline.

> the MC should NACK the partial ADV with an ad-hoc response code.

Yes, it is redundant information, for purposes of error detection. 
Without it, if things get out of sync, then the diffs might be applied 
to the wrong version, without detecting that something is wrong. Or 
*eventually* the application of a diff might fail because the xpath 
refers to something non-existent, but it might happen so late that it is 
difficult to detect what went wrong.

> the topic of the today's discussion.

Based on discussion in design team call today I agree that we don't seem 
to need it.

BUT, I think there is something that will help to guarantee that. If a 
partial adv is *rejected*, then the advertiser should always send a full 
advertisement.

> should end the current CLUE session (CP moves to TERMINATED) and should

My concern is that we prevent any circumstance when we get a "hang" 
situation in the protocol - because a message has been dropped while the 
sender of that message is awaiting a response.

If that situation is *always* resolved via timeouts, then maybe it is 
ok. Even then, actively reporting the error could result in quicker 
error detection. How important that is depends on how long the timeout is.

> that should not be possible if implementing correctly the proposed state

I appreciate wanting to keep things simple. Just not *too* simple. :-)

I'm trying to understand what "wait for message X" *means*, 
operationally. What if, while waiting for a particular type of message, 
some other message type arrives? Is every other type of message ignored 
while awaiting X?

This is made more complicated because we have nested state machines. The 
MC and MP state machines aren't reading from the channel directly. The 
outer state machine reads all the messages from the channel, classifies 
them by type, and then "dispatches" them to the appropriate sub-state 
machine. When it gets a message it can't wait for the chosen state 
machine to get into a suitable state to receive the message - it must 
continue and process any other messages that might arrive.

So when there is a message for the MC or MP state machine, either it 
needs to be queued, or else if the target state machine isn't in the 
proper state to receive it, then it needs to be dropped. Or, each state 
machine could have a "slot" for the *latest* incoming message. If a new 
message arrives and the slot is full, it could be overwritten by the 
newly arrived message, resulting in the older one being dropped.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Thu, 30 Oct 2014 13:52:36 +1100

Hello Paul and Roberta,

> Based on discussion in design team call today I agree that we don't 
> seem to need it.

[CNG] I thought READV the message was needed in case the MP lost the 
CLUE data model information and needed an update. It allowed the MP to 
request an update from the MC. If we remove that what is now the 
assumption?  Can you elaborate, as I wasn't in the meeting?

Regards, Christian

---

From: Roberta Presta <[email-masked]>
Date: Thu, 30 Oct 2014 11:02:59 +0100

Hello Christian,

we found that with the current state machines, in any case the MC might 
need a new copy of the ADV, that copy will arrive even without asking 
for it.
We considered:
- when there might be channel errors for example, or end of session events;
- when the received ADV is nacked by the MC;
- when the MP does not receive any ACK (/NACK/CONF) from the MC
In each of the aforementioned situations, what happens is that the MP 
(sooner or later, thanks to a retry mechanism) will send a new ADV to 
the MC and that the MC will be reached by that ADV.
What is your feeling about these considerations?

Regards,

Roberta