Subject: Re: [clue] Mark's WGLC comments on protocol-04

From: Simon Pietro Romano <[email-masked]>
Date: Mon, 19 Oct 2015 18:12:01 +0200

Hello Mark,

thanks a lot for your comments! My answers/comments are in-line.

> On 17/lug/2015, at 20:26, Duckworth, Mark <[email-masked]> wrote:
> 
> Hi,
> I see no major issues, I just have these minor comments and questions.
>  
> section 1 uses terms MP and MC which aren’t defined, maybe should spell it out here, and define abbreviations in section 2.

Done.

>  section 2 - what’s the difference between CLUE Participant and CLUE-capable device?  The sound the same to me.  Can we just make CLUE Participant a synonym for CLUE-capable device?  Or describe better what the difference is? Also should define abbreviation CP.

My personal view is that the CLUE Participant is not necessarily a “device”, i.e., a hardware entity. It rather represents a generic CLUE-enabled entity, be it a device or a software program.
If this is a useless distinction, we can make them become synonyms.

>  section 4 - clueId - “the identifier of the CP” - this isn’t clear to me. How/where should this identifier be assigned?  Can it be just any string?  Is this meant to be just a name for the CP, administratively assigned?

It is a generic string, as per the protocol schema document. In my view, it is just a name for the CP.

>  “Each CP should manage up to three streams of sequence numbers” - Do we need to define more rules for sequence numbers?  such as:
> -          do they always start at 0 or 1?

I don’t think so. Based on Bob’s comments, we decided to make the sequence number a positive integer (not an unsigned integer anymore). The initial value is freely configurable by the CP (and I would not suggest it to be set to 1 upon session negotiation startup).

> -          do they always increment by 1 for each successive message?

Yes.

> -          if sender is re-sending a message due to timeout or error, does it use same sequence number or a new one?

A new one.

> -          any special rules for handling rollover of the 32 bit value?

No special rules. Having done some work on this with RTP, I am afraid we’re going to open a can of worms if we want to tackle this issue. If others have different feelings, I’ll be glad to catch any good advice!

> -          there is mention of 401 Invalid Sequencing error code for “out of date” sequence number.  How does the receiver detect this, taking rollover into account?

See above. This does not take rollover into account. From the implementation standpoint, I would equip my code with a spaghetti-code if statement like the following:

if(current_seq_num == 65535) expected_seq_num = 1;

Upon session startup, “expected_seq_num" is intialized to the initial sequence number received from the peer, incremented by one. And it gets always updated coherently with this rule, i.e:

- new_seq_number = expected_seq_number —> {current_seq_num = new_seq_number; expected_seq_number = new_seq_number +1;}
- new_seq_number > expected_seq_number (sequence number gap!) —> OK the same!  —> {current_seq_num = new_seq_number; expected_seq_number = new_seq_number +1;}
- new_seq_number < expected_seq_number —> KO!

This approach does not correctly address the case when the sequence number gap happens in proximity to the rollover; though, it should do the job in most of the cases.

> -          Is there any problem if the receiver detects a gap in sequence numbers?  Seems to me this doesn’t have to be treated as an error.

In principle, there is no problem, except for the latest case mentioned above.

>  page 11 typo “whithin” -> “within”

Fixed.

>  section 4.3 para 2 - should also mention simultaneous sets in the list of elements.

Fixed.

>  section 4.5 - ack within configureMessage - if it is included in the message, does that imply a 200 Success response code always? I think the document should say that.

Fixed.

>  
> “The <ack> element SHOULD not be present at all if an ACK message has been already sent back to the MP” - Can we make this MUST instead of SHOULD?

Already fixed (see my response to Bob’s review…)

>  section 4.7 response code table
> Is “reason string” and “response string” supposed to be the same thing?  If so, can we use “reason string” consistently, to match the reasonString element within Ack message?

Sure. Fixed..

>  Section 5 - “Over such a channel there are typically two CLUE streams...”.  I suggest change to “Over such a channel there are typically two CLUE protocol streams...” to avoid confusion between media streams.  Section 2 says “stream” is a capture encoding, but that is not what we are talking about here.

This section has already been modified based on Bob’s review.

>  Section 6 state machine - are the timeout values and retry count thresholds defined anywhere, or is an implementer free to choose anything?

It is an implementer’s choice. Anyhow, I already commented on the retry mechanism when answering Bob’s comments on the ML. Feel free to express your own feeling there.

>  section 7 - “Such a schema is the one included in the yet to come RFC” - it is included in this document section 9

Yep. Fixed.

>  section 10 Examples - should this section be non-normative?

Think so.

Thanks 1k for your comments!

Simon

>  
> Mark
>  
>  
> _______________________________________________
> clue mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/clue <https://www.ietf.org/mailman/listinfo/clue>
                     					       _\\|//_
                           				      ( 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~~~~~~~~~~~~~~~~~~~~~~~~~
					                 \ (            (   )
			                                  \_)          ) /
                                                                       (_/