Subject: [MEDIACTRL] MRB seqnumber

From: Eric Burger <[email-masked]>
Date: Tue, 12 Feb 2013 18:02:01 -0500

The MRB document talks about a seqnumber in a subscription request and notification response. For your laziness, I have included the entirety of the text defining both uses:

5.1.3.1.  <subscription>
[…]
   seqnumber:  indicates a sequence number to be used in conjunction
      with the subscription session id to identify a specific
      subscription command.  The first subscription MUST have 1 as
      'seqnumber', and following subscriptions MUST increment by 1 the
      previous 'seqnumber' value.  The attribute MUST be present.

[…]

5.1.5.  <mrbnotification>
[…]
   seqnumber:  indicates a sequence number to be used in conjunction
      with the subscription session id to identify a specific
      notification update.  The first notification MUST have 1 as
      'seqnumber', and following notifications MUST increment by 1 the
      previous 'seqnumber' value.  The attribute MUST be present.

   It's important to point out that the 'seqnumber' that appears in a
   <mrbnotification> is not related to the 'seqnumber' appearing in a
   <mrbsubscription>.  In fact, the latter is associated with
   subscriptions and would increase at every command issued by the MRB,
   while the former is associated with the asynchronous notifications
   the Media Server would trigger according to the subscription, and as
   such would increase at every notification message to enable the MRB
   keep track of them.
[…]

The AD's are having trouble wrapping their heads around the use of seqnumber. Upon closer inspection, this chair has trouble wrapping his head around the utility of seqnumber.

On the subscribe side, what does it mean in a TCP/DTLS environment, where there is no issue of out-of-sequence request delivery, for there to be an out-of-sequence request? Can anyone tell me the value of seqnumber in this environment? In particular, what does a server do if it gets an out of order request (which cannot happen) or a request gets lost (which cannot happen)?

On the notification side, I *think* I *might* see a value of having monotonically increasing response sequence numbers. If for some reason the server loses a request, the client might figure out that, for a given id, no response ever came. However, in a TCP/DTLS environment, where there is no issue of out-of-sequence notification delivery, what does it mean for the client to receive an out-of-order response (which cannot happen) or a request gets lost (which cannot happen)?

<chair hat off>
Unless there is a reason to keep seqnumber, my vote is to take it out altogether.

If there is a reason to keep seqnumber, then we need to describe what a server does if it gets a request "out of sequence" and what a client does if it gets a response "out of sequence."

Also, if we keep it, I would offer having two attributes that are unrelated having the same name is confusing at best, and will lead to implementation errors at worst. Thus, I would propose we give them different names, like reqseq and respseq.

<chair hat on>
This is the LAST issue holding up publication.  Prompt discussion and resolution is strongly desired.

---

From: Chris Boulton <[email-masked]>
Date: Wed, 13 Feb 2013 12:57:01 +0000

All,

After some discussion we have agreed that the text needs to change 
slightly to address the comment submitted and other queries we have 
received.  The change would result in subscription reading something like:

  seqnumber:  indicates a sequence number to be used in conjunction
       with the subscription session id to identify a specific
       subscription command.  The first subscription MUST contain a 
non-zero number
       'seqnumber', and following subscriptions MUST contain a higher 
number that the
       previous 'seqnumber' value.  If a subsequent 'seqnumber' is not 
higher, a XXX response code is generated
as per section 5.1.4.  The attribute MUST be present.

This also applies to the notification text in section 5.1.5 and the 
following text is proposed:

seqnumber:  indicates a sequence number to be used in conjunction
       with the subscription session id to identify a specific
       notification update.  The first notification update MUST contain 
a non-zero number
       'seqnumber', and following notification updates MUST contain a 
higher number that the
       previous 'seqnumber' value.  If a subsequent 'seqnumber' is not 
higher the situation should
       be considered an error by the entity receiving the notification 
update.  It is implementation
      specific how the receiving entity deals with this situation. The 
attribute MUST be present.

Please let me know if you are OK with these changes.

Thanks.

Chris.

On 12/02/2013 23:02, Eric Burger wrote:
> [...]
> [...]
> [...]
> [...]
> _______________________________________________
> MEDIACTRL mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl

-- 
Chris Boulton
CTO & Co-founder
NS-Technologies <http://www.ns-technologies.com>
m: +44.7876.476681

---

From: Scott McGlashan <[email-masked]>
Date: Wed, 13 Feb 2013 13:06:49 +0000

Sounds good Chris. +1 from me.

thanks

Scott

On 13 Feb 2013, at 12:57, Chris Boulton <[email-masked]> wrote:

> All,
> 
> After some discussion we have agreed that the text needs to change slightly to address the comment submitted and other queries we have received.  The change would result in subscription reading something like:
> 
>       subscription command.  The first subscription MUST contain a non-zero number 
>       'seqnumber', and following subscriptions MUST contain a higher number that the
>       previous 'seqnumber' value.  If a subsequent 'seqnumber' is not higher, a XXX response code is generated
> This also applies to the notification text in section 5.1.5 and the following text is proposed:
> 
>       notification update.  The first notification update MUST contain a non-zero number 
>       'seqnumber', and following notification updates MUST contain a higher number that the
>       previous 'seqnumber' value.  If a subsequent 'seqnumber' is not higher the situation should
>       be considered an error by the entity receiving the notification update.  It is implementation
>      specific how the receiving entity deals with this situation.  The attribute MUST be present.
> 
> NS-Technologies

---

From: Lorenzo Miniero <[email-masked]>
Date: Thu, 14 Feb 2013 11:11:41 +0100

On Wed, 13 Feb 2013 12:57:01 +0000

> Please let me know if you are OK with these changes.

Of course I support them all: +1 from me as well.

L.

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 14 Feb 2013 11:37:20 +0100

+1 from here.

Simon

>>> This is the LAST issue holding up publication.  Prompt discussion and resolution is strongly desired.

                     					       _\\|//_
                           				      ( 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: Burger Eric <[email-masked]>
Date: Thu, 14 Feb 2013 11:43:05 -0500

Me, too.

---

From: Tobia Castaldi UniNa <[email-masked]>
Date: Fri, 15 Feb 2013 13:00:04 +0100

+1
Tobia

Il 14/02/2013 17.43, Burger Eric ha scritto:
> Me, too.
>
> On Feb 14, 2013, at 5:37 AM, Simon Pietro Romano <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> +1 from here.
>>
>> Simon
>>
>>> Chris Boulton <[email-masked] 
>>> <mailto:[email-masked]>> wrote:
>>>
>>>> All,
>>>>
>>>>> The MRB document talks about a seqnumber in a subscription request 
>>>>> and notification response. For your laziness, I have included the 
>>>>> entirety of the text defining both uses:
>>>>>
>>>>> 5.1.3.1.  <subscription>
>>>>> [...]
>>>>> The AD's are having trouble wrapping their heads around the use of 
>>>>> seqnumber. Upon closer inspection, this chair has trouble wrapping 
>>>>> his head around the utility of seqnumber.
>>>>>
>>>>> On the subscribe side, what does it mean in a TCP/DTLS 
>>>>> environment, where there is no issue of out-of-sequence request 
>>>>> delivery, for there to be an out-of-sequence request? Can anyone 
>>>>> tell me the value of seqnumber in this environment? In particular, 
>>>>> what does a server do if it gets an out of order request (which 
>>>>> cannot happen) or a request gets lost (which cannot happen)?
>>>>>
>>>>> On the notification side, I *think* I *might* see a value of 
>>>>> having monotonically increasing response sequence numbers. If for 
>>>>> some reason the server loses a request, the client might figure 
>>>>> out that, for a given id, no response ever came. However, in a 
>>>>> TCP/DTLS environment, where there is no issue of out-of-sequence 
>>>>> notification delivery, what does it mean for the client to receive 
>>>>> an out-of-order response (which cannot happen) or a request gets 
>>>>> lost (which cannot happen)?
>>>>>
>>>>> <chair hat off>
>>>>> If there is a reason to keep seqnumber, then we need to describe 
>>>>> what a server does if it gets a request "out of sequence" and what 
>>>>> a client does if it gets a response "out of sequence."
>>>>>
>>>>> Also, if we keep it, I would offer having two attributes that are 
>>>>> unrelated having the same name is confusing at best, and will lead 
>>>>> to implementation errors at worst. Thus, I would propose we give 
>>>>> them different names, like reqseq and respseq.
>>>>>
>>>>>
>>>>> <chair hat on>
>>>>> [email-masked] <mailto:[email-masked]>
>>>> NS-Technologies <http://www.ns-technologies.com 
>>>> <http://www.ns-technologies.com/>>
>>>> m: +44.7876.476681
>>>
>>>
>>> -- 
>>> Lorenzo Miniero, COB
>>>
>>> Meetecho s.r.l.
>>> http://www.meetecho.com <http://www.meetecho.com/>
>>> [email-masked] <mailto:[email-masked]>
>>      e-mail: [email-masked] <mailto:[email-masked]>
>>
>> [email-masked] <mailto:[email-masked]>