Re: [MEDIACTRL] MRB seqnumber

[Chris Boulton <[e-mail]>]

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:
> 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]
> 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