Re: [MEDIACTRL] MRB seqnumber

[Tobia Castaldi UniNa <[e-mail]>]

+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 <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>> +1 from here.
>>
>> Simon
>>
>> Il giorno 14/feb/2013, alle ore 11:11, Lorenzo Miniero ha scritto:
>>
>>> On Wed, 13 Feb 2013 12:57:01 +0000
>>> Chris Boulton <[e-mail] 
>>> <mailto:[e-mail]>> 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:
>>>>
>>>>  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.
>>>>
>>>
>>>
>>> Of course I support them all: +1 from me as well.
>>>
>>> L.
>>>
>>>> Thanks.
>>>>
>>>> Chris.
>>>>
>>>>
>>>> On 12/02/2013 23:02, Eric Burger wrote:
>>>>> 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.
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> MEDIACTRL mailing list
>>>>> [e-mail] <mailto:[e-mail]>
>>>>> 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 
>>>> <http://www.ns-technologies.com/>>
>>>> m: +44.7876.476681
>>>
>>>
>>> -- 
>>> Lorenzo Miniero, COB
>>>
>>> Meetecho s.r.l.
>>> Web Conferencing and Collaboration Tools
>>> http://www.meetecho.com <http://www.meetecho.com/>
>>> _______________________________________________
>>> MEDIACTRL mailing list
>>> [e-mail] <mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/mediactrl
>>> Supplemental Web Site:
>>> http://www.standardstrack.com/ietf/mediactrl
>>>
>>
>>     _\\|//_
>>     ( O-O )
>>  ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
>> Simon Pietro Romano
>> Universita' di Napoli Federico II
>>    Computer Engineering Department
>>            Phone: [phone] -- Fax: [phone]
>>      e-mail: [e-mail] <mailto:[e-mail]>
>>
>>   <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli
>>  idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>>                    oooO
>>   ~~~~~~~~~~~~~~~~~~~~~~~( )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
>>                \ (            (   )
>>                                 \_)      ) /
>>                                  (_/
>>
>>
>>
>>
>>
>> _______________________________________________
>> MEDIACTRL mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/mediactrl
>> Supplemental Web Site:
>> http://www.standardstrack.com/ietf/mediactrl
>
>
>
> _______________________________________________
> MEDIACTRL mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl