Subject: [clue] Protocol draft attempt

From: Simon Pietro Romano <[email-masked]>
Date: Wed, 10 Jul 2013 19:19:10 +0200

Hello guys,

as you probably noticed, we have just submitted a first attempt at defining a state machine for both the CLUE Media Producer and CLUE Media Consumer entities.

http://www.ietf.org/id/draft-presta-clue-protocol-00.txt

Please have a look at it and treat it like no more than a first stone in the lake of discussion!

Cheers,

Simon

                     					       _\\|//_
                           				      ( O-O )
   ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                    				Simon Pietro Romano
             				 Universita' di Napoli Federico II
                		     Computer Engineering Department 
	             Phone: +39 081 7683823 -- Fax: +39 081 7683816
                                           e-mail: [email-masked]

		    <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli 
		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
               			                     oooO
  ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 10 Jul 2013 17:22:41 -0400

(as individual)

Simon & Paula,

Thanks for doing this! I have some questions about it:

You have separate state machines for MP and MC, and note that typically 
a node will be both. Are you assuming the messages for both will flow 
over the same data channel? (I assume so.) If so, then I guess there 
must be a low level demux that sorts out the incoming messages and 
directs them to either the MP or MC state machine. And if it becomes 
necessary to add any other messages it will be necessary to ensure that 
the same message type can't be received by both the MC and the MP.

You propose that RE-ADV contain a reason. While I understand 'refresh' 
as a reason, don't the other reasons you mention duplicate the response 
code that would presumably have been sent first? If the reason is 
because there was something incorrect in the prior ADV, is there any 
reason to expect that it will get better when retried? I guess we at 
least ought to recognize that some things can't be fixed by RE-ADV, and 
have a more extreme transition. (Perhaps to reinitialize the data channel.)

Re both state machines:

obviously we need to think about timeouts. ISTM that however we set the 
timeout value, it can result from either a transport level problem or an 
application level problem. Presumably transport level problems will be 
detected by the transport itself, and we may have no control over the 
timeout level for that. If its like TCP, then it is probably longer than 
we would want to wait, so we may get a timeout at application level that 
reflects a transport problem, and that can't be distinguished from an 
application level problem.

If its a transport problem, then there is no point in retrying, since 
the reliable transport will have done what it can and an application 
level retry will be behind that.

Even if we knew we had an application level problem, is it worthwhile to 
retry it over the same data channel?

I see that you call for every ADV to get a response. Were you thinking 
of a tight timeout here, or a loose one.

In MC state machine:

I think it will be easy to get into an infinite loop between ADV 
RECEIVED and TRYING when the CONF is not acceptable. We need to find a 
way to break that loop. Again, I'm not sure how ofter a retry at this 
level will be helpful.

I think there is a missing transition: if in TRYING due to having sent a 
CONF from IN CALL, then it is possible to receive another ADV before the 
response to the CONF. This is also the case where the subsequent 
response to the CONF might be an error. But then the fix is to send a 
CONF to the *new* ADV, rather than the old one.

In MP state machine:

If in WAIT FOR CONF and take the "change tp settings" transition, will 
end up back in WAIT FOR CONF. But now there will be *two* CONFs coming, 
one for each ADV sent. Assuming the messages are properly coded, then it 
will be possible to detect that one is for the wrong ADV. I guess this 
is covered by the "send error response" transition from CONF RECEIVED to 
WAIT FOR CONF. But, as above, having this singe error transition opens 
possibility of an infinite loop. Can fix this one with a separate 
transition from CONF RECEIVED to itself when the received CONF is for 
and old ADV.

	Thanks,
	Paul

On 7/10/13 1:19 PM, Simon Pietro Romano wrote:
> Hello guys,
>
> as you probably noticed, we have just submitted a first attempt at
> defining a state machine for both the CLUE Media Producer and CLUE Media
> Consumer entities.
>

---

From: Roberta Presta <[email-masked]>
Date: Thu, 11 Jul 2013 17:13:50 +0200

Hi Paul,

please see below.

Il 10/07/2013 23:22, Paul Kyzivat ha scritto:
> You have separate state machines for MP and MC, and note that 
> typically a node will be both. Are you assuming the messages for both 
> will flow over the same data channel? (I assume so.)
Yes, we assume the messages flowing over the same data channel.
> If so, then I guess there must be a low level demux that sorts out the 
> incoming messages and directs them to either the MP or MC state 
> machine. And if it becomes necessary to add any other messages it will 
> be necessary to ensure that the same message type can't be received by 
> both the MC and the MP.
>
Exactly.

> You propose that RE-ADV contain a reason.
> While I understand 'refresh' as a reason, don't the other reasons you 
> mention duplicate the response code that would presumably have been 
> sent first?
> If the reason is because there was something incorrect in the prior 
> ADV, is there any reason to expect that it will get better when retried?
> I guess we at least ought to recognize that some things can't be fixed 
> by RE-ADV, and have a more extreme transition. (Perhaps to 
> reinitialize the data channel.)
>
Probably it is better to keep semantically apart the request of a 
refresh from the notification of advertisement errors.

However, something could be automatically modified (both in the ADV and 
in the CONF) when the rejection reason is understood - for example a not 
supported option/extension/version could be omitted or changed, or a 
malformed and optional XML part of the message could be removed.

About response codes/reason phrases, even if there is overlapping, we 
have started to consider separately errors delivered to the MP and 
errors delivered to the MC.

> Re both state machines:
>
> obviously we need to think about timeouts.
> ISTM that however we set the timeout value, it can result from either 
> a transport level problem or an application level problem.
> Presumably transport level problems will be detected by the transport 
> itself, and we may have no control over the timeout level for that.
> If its like TCP, then it is probably longer than we would want to 
> wait, so we may get a timeout at application level that reflects a 
> transport problem, and that can't be distinguished from an application 
> level problem.
>
> Even if we knew we had an application level problem, is it worthwhile 
> to retry it over the same data channel?
>
Undoubtely timeouts are needed, they are a common application-level 
solution exploited even when the underlying transport channel is reliable.
Clearly the timeout settings should take into account the possible 
transport-level timers.

> of a tight timeout here, or a loose one.
When an ADV is sent, the MP waits for a message coming from the MC, 
hopefully a CONF (WAIT FOR CONF).
However, other events can happen like a change in the tp settings of a 
refresh request coming from the MC. These events triggers a new ADV 
updating the previous one and resetting the timer.
If nothing happens and the timeout expires, and there are less than N 
exceeded timeouts, then a new ADV is sent and the previous one is 
considered expired.
I am not sure of having understood your question :)

> way to break that loop. Again, I'm not sure how ofter a retry at this 

You are right, there is a possible loop. It has to be managed with a 
retry counter mechanism.

>
> I think there is a missing transition: if in TRYING due to having sent 
> a CONF from IN CALL, then it is possible to receive another ADV before 
> the response to the CONF. This is also the case where the subsequent 
Yes, there is a missing transition and you provide the solution.
When in TRYING, if a new ADV  arrives (ADV-2), the MC moves to the ADV 
RECEIVED state.
Here, if arrives the response to the CONF-1 before the CONF-2 is issued, 
there should be a self-transition that keeps the MC into the ADV 
RECEIVED state preparing the CONF-2 command (i.e., ignoring the -error- 
response to CONF-1 coming from the MP).

> end up back in WAIT FOR CONF. But now there will be *two* CONFs 
> coming, one for each ADV sent. Assuming the messages are properly 
> coded, then it will be possible to detect that one is for the wrong 
> ADV. I guess this is covered by the "send error response" transition 
> from CONF RECEIVED to WAIT FOR CONF.
You guess right, maybe it needs to be clarified both in the text and in 
the diagram.
> But, as above, having this singe error transition opens possibility of 
> an infinite loop. Can fix this one with a separate transition from 
> CONF RECEIVED to itself when the received CONF is for and old ADV.
>
There is the possibility of an infinite loop between WAIT FOR CONF and 
CONF RECEIVED if the CONF keeps to be rejected. This problem could be 
solved with a retry counter too.

Cheers,

Roberta

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