Re: [MEDIACTRL] MRB seqnumber
Simon Pietro Romano <spromano@unina.it> Thu, 14 February 2013 10:37 UTC
Return-Path: <spromano@unina.it>
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 5B25021F865B for <mediactrl@ietfa.amsl.com>; Thu, 14 Feb 2013 02:37:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.718
X-Spam-Level:
X-Spam-Status: No, score=-100.718 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 GlN5nwLQF5mo for <mediactrl@ietfa.amsl.com>; Thu, 14 Feb 2013 02:37:24 -0800 (PST)
Received: from smtp2.unina.it (smtp2.unina.it [192.132.34.62]) by ietfa.amsl.com (Postfix) with ESMTP id C8EFA21F8654 for <mediactrl@ietf.org>; Thu, 14 Feb 2013 02:37:23 -0800 (PST)
Received: from [143.225.229.230] ([143.225.229.230]) (authenticated bits=0) by smtp2.unina.it (8.14.4/8.14.4) with ESMTP id r1EAbKN2004951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 14 Feb 2013 11:37:20 +0100
Mime-Version: 1.0 (Apple Message framework v1283)
Content-Type: multipart/alternative; boundary="Apple-Mail=_808EC88B-DEAF-40D3-86A9-9426BBA3A9DC"
From: Simon Pietro Romano <spromano@unina.it>
In-Reply-To: <20130214111141.1be4b19a@rainpc>
Date: Thu, 14 Feb 2013 11:37:20 +0100
Message-Id: <CC4389D1-CEB4-4E04-A5E1-923BB836C46B@unina.it>
References: <4C39824D-E014-4893-B6F9-6DE10C2F0557@standardstrack.com> <511B8D9D.6070506@ns-technologies.com> <20130214111141.1be4b19a@rainpc>
To: Lorenzo Miniero <lorenzo@meetecho.com>
X-Mailer: Apple Mail (2.1283)
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: Thu, 14 Feb 2013 10:37:25 -0000
+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] MRB seqnumber Eric Burger
- Re: [MEDIACTRL] MRB seqnumber Chris Boulton
- Re: [MEDIACTRL] MRB seqnumber Scott McGlashan
- Re: [MEDIACTRL] MRB seqnumber Lorenzo Miniero
- Re: [MEDIACTRL] MRB seqnumber Simon Pietro Romano
- Re: [MEDIACTRL] MRB seqnumber Burger Eric
- Re: [MEDIACTRL] MRB seqnumber Tobia Castaldi UniNa