Re: [Dime] OVLI: comments to 4.1

Ben Campbell <ben@nostrum.com> Mon, 09 December 2013 22:46 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B4981AE087 for <dime@ietfa.amsl.com>; Mon, 9 Dec 2013 14:46:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.036
X-Spam-Level:
X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s5ewWc3AWxAE for <dime@ietfa.amsl.com>; Mon, 9 Dec 2013 14:46:54 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id A3AFD1AE07F for <dime@ietf.org>; Mon, 9 Dec 2013 14:46:54 -0800 (PST)
Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rB9MkmpA032679 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 9 Dec 2013 16:46:49 -0600 (CST) (envelope-from ben@nostrum.com)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\))
From: Ben Campbell <ben@nostrum.com>
In-Reply-To: <52A5E813.60801@usdonovans.com>
Date: Mon, 09 Dec 2013 16:46:46 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <7AE3F729-B987-45B1-A9AF-2F0C9A36641E@nostrum.com>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <6CDCFC84-3048-40B9-91A4-1451FCC65F60@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519DCE5@DEMUMBX014.nsn-intra.net> <09616DA2-D1ED-40EE-8E89-755DFCD81092@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E02B@DEMUMBX014.nsn-intra.net> <1A402C59-E390-4C95-8E30-97F1F9D3EF0F@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E05C@DEMUMBX014.nsn-intra.net> <790F1603-64D5-40E2-BC59-FD4C104EEF1B@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E0D9@DEMUMBX014.nsn-intra.net> <52A5E813.60801@usdonovans.com>
To: Steve Donovan <srdonovan@usdonovans.com>
X-Mailer: Apple Mail (2.1822)
Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism)
Cc: "dime@ietf.org list" <dime@ietf.org>
Subject: Re: [Dime] OVLI: comments to 4.1
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 09 Dec 2013 22:46:55 -0000

On Dec 9, 2013, at 9:56 AM, Steve Donovan <srdonovan@usdonovans.com> wrote:

> Ulrich,
> 
> Looking at the impacts of removing the sequence number from the feature vector AVP.  This would require the following logic for each request received at the reporting node:
> 
> Parse the full set of OC-Feature-Vector AVPs 
> Calculate the set of overlapping capabilities
> Generate the reporting nodes OC-Feature-Vector AVPs
> If the reporting node is in overload then generate and append the OC-OLR AVPs.
> 
> Keeping the version number requires the reporting node to do the following:
> 
> Parse the feature vector sequence number
> If the sequence number is changed from the last version number received then 
>   Parse the remaining OC-Feature-Vector AVPs
>   Calculate the set of overlapping capabilities
>   Generate the reporting nodes capability AVPs
>   Save the version number and results of capabilities exchange
> If the reporting node is in overload then generate and append the OC-OLR AVPs.
> 
> Removing the sequence number forces the reporting node to do extra work for all requests, including requests received when overloaded.  Given that the sequence number will almost never change, this seems like a bad idea.  We should be reducing the work of overloaded nodes, not increasing it.

It's worth pointing out that, if someone believes the sequence number comparison is not worth the trouble, they can always ignore it and revert to Steve's first example.