Re: [MEDIACTRL] MRB seqnumber

Scott McGlashan <smcg.stds01@mcglashan.org> Wed, 13 February 2013 13:06 UTC

Return-Path: <smcg.stds01@mcglashan.org>
X-Original-To: mediactrl@ietfa.amsl.com
Delivered-To: mediactrl@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75AEE21F885C for <mediactrl@ietfa.amsl.com>; Wed, 13 Feb 2013 05:06:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7gUH05aeLaOB for <mediactrl@ietfa.amsl.com>; Wed, 13 Feb 2013 05:06:54 -0800 (PST)
Received: from csmtp2.one.com (csmtp2.one.com [91.198.169.22]) by ietfa.amsl.com (Postfix) with ESMTP id C96CC21F8842 for <mediactrl@ietf.org>; Wed, 13 Feb 2013 05:06:53 -0800 (PST)
Received: from [192.168.0.34] (host81-132-170-45.range81-132.btcentralplus.com [81.132.170.45]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by csmtp2.one.com (Postfix) with ESMTPSA id 653C0301769F; Wed, 13 Feb 2013 13:06:50 +0000 (UTC)
Content-Type: multipart/alternative; boundary="Apple-Mail=_B44C8E47-3D2C-4466-B83F-85D7F6B7BAE5"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: Scott McGlashan <smcg.stds01@mcglashan.org>
In-Reply-To: <511B8D9D.6070506@ns-technologies.com>
Date: Wed, 13 Feb 2013 13:06:49 +0000
Message-Id: <2BA7543D-69BB-446F-8685-0C98CDBEB2BB@mcglashan.org>
References: <4C39824D-E014-4893-B6F9-6DE10C2F0557@standardstrack.com> <511B8D9D.6070506@ns-technologies.com>
To: Chris Boulton <chris-standards@ns-technologies.com>
X-Mailer: Apple Mail (2.1499)
Cc: mediactrl@ietf.org
Subject: Re: [MEDIACTRL] MRB seqnumber
X-BeenThere: mediactrl@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Media Control WG Discussion List <mediactrl.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mediactrl>
List-Post: <mailto:mediactrl@ietf.org>
List-Help: <mailto:mediactrl-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mediactrl>, <mailto:mediactrl-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Feb 2013 13:06:55 -0000

Sounds good Chris. +1 from me.

thanks

Scott

On 13 Feb 2013, at 12:57, Chris Boulton <chris-standards@ns-technologies.com> 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.
> 
> 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
>> MEDIACTRL@ietf.org
>> https://www.ietf.org/mailman/listinfo/mediactrl
>> Supplemental Web Site:
>> http://www.standardstrack.com/ietf/mediactrl
> 
> 
> -- 
> Chris Boulton
> CTO & Co-founder
> NS-Technologies
> m: +44.7876.476681
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl