Re: [MEDIACTRL] MRB seqnumber

[Lorenzo Miniero <[e-mail]>]

On Wed, 13 Feb 2013 12:57:01 +0000
Chris Boulton <[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]
> > 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


-- 
Lorenzo Miniero, COB

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