Re: [MEDIACTRL] MRB seqnumber

Burger Eric <eburger@cs.georgetown.edu> Thu, 14 February 2013 16:43 UTC

Return-Path: <eburger@cs.georgetown.edu>
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 B545C21F8614 for <mediactrl@ietfa.amsl.com>; Thu, 14 Feb 2013 08:43:05 -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 ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qYkqqDc4FBI for <mediactrl@ietfa.amsl.com>; Thu, 14 Feb 2013 08:43:04 -0800 (PST)
Received: from karma.cs.georgetown.edu (karma.cs.georgetown.edu [141.161.20.3]) by ietfa.amsl.com (Postfix) with ESMTP id D0CD821F85EA for <mediactrl@ietf.org>; Thu, 14 Feb 2013 08:43:03 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by karma.cs.georgetown.edu (Postfix) with ESMTP id F0AED433E6 for <mediactrl@ietf.org>; Thu, 14 Feb 2013 11:43:02 -0500 (EST)
X-Virus-Scanned: by amavisd-new at cs.georgetown.edu
Received: from karma.cs.georgetown.edu ([127.0.0.1]) by localhost (karma.cs.georgetown.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3ktiFQsWpD3T for <mediactrl@ietf.org>; Thu, 14 Feb 2013 11:43:01 -0500 (EST)
Received: from [141.161.20.235] (unknown [141.161.20.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by karma.cs.georgetown.edu (Postfix) with ESMTP id 4785F43396 for <mediactrl@ietf.org>; Thu, 14 Feb 2013 11:43:01 -0500 (EST)
From: Burger Eric <eburger@cs.georgetown.edu>
Content-Type: multipart/alternative; boundary="Apple-Mail=_5D531292-E711-4071-BB3A-E702BB4728CB"
Message-Id: <896AC59D-662C-4EA7-AF31-47535841D132@cs.georgetown.edu>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
Date: Thu, 14 Feb 2013 11:43:05 -0500
References: <4C39824D-E014-4893-B6F9-6DE10C2F0557@standardstrack.com> <511B8D9D.6070506@ns-technologies.com> <20130214111141.1be4b19a@rainpc> <CC4389D1-CEB4-4E04-A5E1-923BB836C46B@unina.it>
To: "mediactrl@ietf.org" <mediactrl@ietf.org>
In-Reply-To: <CC4389D1-CEB4-4E04-A5E1-923BB836C46B@unina.it>
X-Mailer: Apple Mail (2.1499)
X-Mailman-Approved-At: Thu, 14 Feb 2013 08:49:38 -0800
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: Thu, 14 Feb 2013 16:43:05 -0000

Me, too.

On Feb 14, 2013, at 5:37 AM, Simon Pietro Romano <spromano@unina.it>; 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 <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.
>>> 
>> 
>> 
>> 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
>>>> 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 <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
>> _______________________________________________
>> MEDIACTRL mailing list
>> MEDIACTRL@ietf.org
>> 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: +39 081 7683823 -- Fax: +39 081 7683816
>                                            e-mail: spromano@unina.it
> 
> 		    <<Molti mi dicono che lo scoraggiamento Ë l'alibi degli 
> 		    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
>                			                     oooO
>   ~~~~~~~~~~~~~~~~~~~~~~~(   )~~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
> 					                 \ (            (   )
> 			                                  \_)          ) /
>                                                                        (_/
> 
> 
> 
> 
> 
> _______________________________________________
> MEDIACTRL mailing list
> MEDIACTRL@ietf.org
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl