[MEDIACTRL] MRB seqnumber

Eric Burger <eburger@standardstrack.com> Tue, 12 February 2013 23:02 UTC

Return-Path: <eburger@standardstrack.com>
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 E599521F88CC for <mediactrl@ietfa.amsl.com>; Tue, 12 Feb 2013 15:02:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.024
X-Spam-Level:
X-Spam-Status: No, score=-102.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 4O2jop2Q-LEm for <mediactrl@ietfa.amsl.com>; Tue, 12 Feb 2013 15:02:04 -0800 (PST)
Received: from biz104.inmotionhosting.com (biz104.inmotionhosting.com [74.124.215.15]) by ietfa.amsl.com (Postfix) with ESMTP id 65EA521F88A0 for <mediactrl@ietf.org>; Tue, 12 Feb 2013 15:02:01 -0800 (PST)
Received: from ip68-100-199-8.dc.dc.cox.net ([68.100.199.8]:65390 helo=[192.168.15.177]) by biz104.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.80) (envelope-from <eburger@standardstrack.com>) id 1U5OrJ-0006Zv-SX for mediactrl@ietf.org; Tue, 12 Feb 2013 15:01:54 -0800
From: Eric Burger <eburger@standardstrack.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_1DDFB521-F2D5-4ABE-BAEE-ECB6156ECF7E"; protocol="application/pkcs7-signature"; micalg=sha1
Message-Id: <4C39824D-E014-4893-B6F9-6DE10C2F0557@standardstrack.com>
Date: Tue, 12 Feb 2013 18:02:01 -0500
To: "mediactrl@ietf.org" <mediactrl@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
X-Mailer: Apple Mail (2.1499)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - biz104.inmotionhosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - standardstrack.com
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: [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: Tue, 12 Feb 2013 23:02:05 -0000

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.