Re: [Dime] OVLI: comments to 4.1

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Thu, 12 December 2013 15:23 UTC

Return-Path: <ulrich.wiehe@nsn.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 5821C1AE301 for <dime@ietfa.amsl.com>; Thu, 12 Dec 2013 07:23:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
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 orj_mBxmJSfg for <dime@ietfa.amsl.com>; Thu, 12 Dec 2013 07:23:05 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7694E1A1F61 for <dime@ietf.org>; Thu, 12 Dec 2013 07:23:04 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rBCFMu47025705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Dec 2013 16:22:56 +0100
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rBCFMuFl011322 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 12 Dec 2013 16:22:56 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Thu, 12 Dec 2013 16:22:55 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] OVLI: comments to 4.1
Thread-Index: Ac7xvTHHIECkLcDwSDuVAh2ACeOasAAprlMAAAaV6CAAlFJBAAADLijg///yiAD//+yxwIAAG3gA///jPWCAAV/bAP//0rCwAAujOgD//+gx4P//PIoA//3FKSD/+zWWgP/1DNgg/+nfowD/05n2AA==
Date: Thu, 12 Dec 2013 15:22:55 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519E9BE@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D90006681519DA3E@DEMUMBX014.nsn-intra.net> <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> <C1AC0D6D-EDA2-41E2-8FB9-CB82D2D409DA@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E331@DEMUMBX014.nsn-intra.net> <D1780C1C-D939-466E-8B04-3663F8888B23@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E3C4@DEMUMBX014.nsn-intra.net> <0CDBF4BB-4E38-41D6-A5E2-9218FFEFEA43@gmail.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E6EF@DEMUMBX014.nsn-intra.net> <52A869AD.6080305@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D90006681519E89B@DEMUMBX014.nsn-intra.net> <52A9C040.40206@usdonovans.com>
In-Reply-To: <52A9C040.40206@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.100]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D90006681519E9BEDEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 40733
X-purgate-ID: 151667::1386861777-00000661-1D831E72/0-0/0-0
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: Thu, 12 Dec 2013 15:23:14 -0000

Steve,

you probably mean "...can't  be optional..." rather than "...can't be mandatory..."

If so, I understand your logic but this means that  reacting nodes are forced to  implement sequence numbers in OC-Supported-Features just because some reporting nodes prefer to do things complicated rather than simple and I'm not convinced that this would be the way to go.

Ulrich


From: ext Steve Donovan [mailto:srdonovan@usdonovans.com]
Sent: Thursday, December 12, 2013 2:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org
Subject: Re: [Dime] OVLI: comments to 4.1

Ulrich,

No, the sequence number can't be mandatory.  It always needs to be sent to allow for end-points that what to use the logic I proposed.

An endpoint that receives the sequence number can choose to ignore it, but endpoints must always send sequence numbers.

Steve
On 12/12/13 3:30 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Steve,

do you mean " keep sequence number in OC-Supported-Features as an optional AVP that may be ignored by the receiver and need notbe included by the sender"?

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Wednesday, December 11, 2013 2:34 PM
To: dime@ietf.org<mailto:dime@ietf.org>
Subject: Re: [Dime] OVLI: comments to 4.1

Ulrich,

My email showed how a reporting node could avoid the work of recalculating capability information on a message by message basis using the sequence number.  This approach does require maintaining state.

As Ben pointed out, it is also possible to not follow my logic and do as you propose by ignoring the sequence number and going through the work of calculating the response every time.

Which approach to take is clearly an implementation decision.  We should keep the sequence number to allow for the stateful approach for implementations that are willing to take advantage of maintaining state to avoid work.

Steve
On 12/11/13 1:34 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:

Jouni,



I do not agree.



My statement was general: reporting node may be server or SFA; supported features may be defined features (default algo) or future extensions.



Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Tuesday, December 10, 2013 10:46 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org<mailto:dime@ietf.org>

Subject: Re: [Dime] OVLI: comments to 4.1



Ulrich,



On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com><mailto:ulrich.wiehe@nsn.com> wrote:







-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Tuesday, December 10, 2013 12:32 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org<mailto:dime@ietf.org>

Subject: Re: [Dime] OVLI: comments to 4.1





On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com><mailto:ulrich.wiehe@nsn.com> wrote:



Hi Jouni,



my understanding from Steve's clarification was that the reporting node would setup and maintain a database of "states", one per reacting node where a state of a reacting node is identified by a sequence number and the database entry would contain the pre-calculated OLR.

Hard to see how this is done without consuming resources.



It is mostly static information. Still I do not see how

you would get away without any state.

[Wiehe, Ulrich (NSN - DE/Munich)] There is no need for the reporting node to store and maintain information per reacting node because the reacting node actually tells within the request message all information the reporting node needs to know. The reporting node simply fetches the pre-calculated OLR that matches the supported features of the reacting node as indicated in the request and appends it to the answer.



This could be true for the default algorithm in this spec. However,

given the extension mechanism we have in place it is quite possible

that the assumption does not hold for new features.



Also, if I were to implement a server front end agent that would

definitely need state and still ought to comply the protocol spec.



- Jouni









Furthermore,

Why would the reacting node be interested in config changes of the reporting node?

Isn't it so that the reacting node is only interested in OLR changes?



Sigh.. say the traffic abatement algorithm changes or new features

get added. Those have more impact than just OLR change.



- Jouni





Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Tuesday, December 10, 2013 9:41 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org<mailto:dime@ietf.org>

Subject: Re: [Dime] OVLI: comments to 4.1





On Dec 9, 2013, at 4:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com><mailto:ulrich.wiehe@nsn.com> wrote:



But maintaining a specific state per reacting node is very resource consuming for the (overloaded) reporting node. It is simpler and more efficient to base any processing logic on actual information received in the request rather than on information stored from previous communication.



The "state" in a reporting node is merely the current configuration

and a counter for sequence number. Hard to me see that as resource

consuming function.



And the earlier comment of mine is done from reacting node point

of view, since it is more interested in the possible config changes

in the reporting node (e.g. S6a is stateless application, configuration

can change at any time).



- Jouni







Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Monday, December 09, 2013 2:25 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org<mailto:dime@ietf.org>

Subject: Re: [Dime] OVLI: comments to 4.1





On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com><mailto:ulrich.wiehe@nsn.com> wrote:



There is a fundamental difference:

OLRs need to be stored, Feature-Vectors not.



How come feature vector does not need to be stored? I do not

get that? I would set my implementation to a specific state

or mode based on the feature vector. When that changes I'd

like to know that. And then keep functioning based on that.



- Jouni



When receiving an OLR you may want to know whether its worth the effort to replace an already stored OLR with the received OLR.

When receiving a Feature-Vector you just act on it.



Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Monday, December 09, 2013 1:55 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org<mailto:dime@ietf.org>

Subject: Re: [Dime] OVLI: comments to 4.1





In the same vein as folks wanted send OLRs with the new or old information,

the feature vector should behave in a same way IMHO. That implies there are

situations when a reception of the feature vector does not change anything

in an endpoint current behavior.



- Jouni



On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com><mailto:ulrich.wiehe@nsn.com> wrote:



Isn't it so that the Feature-Vector (if present) always contains something that an implementation needs to act upon?



Ulrich



-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Monday, December 09, 2013 1:12 PM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org<mailto:dime@ietf.org>

Subject: Re: [Dime] OVLI: comments to 4.1



Ulrich,



On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com><mailto:ulrich.wiehe@nsn.com> wrote:



Hi Jouni,



thank you for your response.



With regard to 3)

I still fail to see the usecase for Sequence-Number or TimeStamp within OC-Feature-Vector. Please clarify.



Since we also allow extending the OC-Feature-Vector beyond recognition,

it has good chances become a rather complex grouped AVP. In that context

the Sequence-Number allows an easy and quick way to check if the feature

vector contains something that an implementation needs to act upon.



With regard to 4)

This was not obvious to me. (The obvious typo is the missing "of" between "one" and "the").



Ack. Fixed the missing 'of'.



- Jouni





Best regards

Ulrich





-----Original Message-----

From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]

Sent: Friday, December 06, 2013 11:17 AM

To: Wiehe, Ulrich (NSN - DE/Munich)

Cc: dime@ietf.org<mailto:dime@ietf.org>

Subject: Re: [Dime] OVLI: comments to 4.1





On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com><mailto:ulrich.wiehe@nsn.com> wrote:



Dear all,



here are comments to clause 4.1:



1. The OC-Feature-Vector AVP is no longer a vector; the name of the AVP may be misleading. Proposal is to rename it to "OC-Supported-Features AVP"



OK with me.



2. The OC-Feature AVP is a vector of features. Proposal is to rename it to "OC-Feature-Vector AVP"



OK with me.



3. The OC-Sequence-Number within OC-Feature-Vector only makes sense if the receiving reporting endpoint can determine the identity of the reacting endpoint (which is not necessarily the origin host (client),



My original proposal was to have seqnr as a timestamp. Some folks argued

it is no good and suggested seqnr. I still think time makes more sense than

seqnr.



it may be an agent and it may not always be the same agent), and if the reporting endpoint is required to store the OC-Feature-Vector / reacting-endpoint-identity pair (which I think both is not required). The reporting endpoint can base its processing logic on the actually received OC-Feature-Vector value, no matter whether it is brand-new or old but stil valid. Proposal is to delete OC-Sequence-Number AVP from OC-Feature-Vector.



Do not agree removing it.



4. The text



The reporting node that sends the answer also includes the OC-

Feature-Vector AVP that describe the capabilities it supports.  The

set of capabilities advertised by the reporting node depends on local

policies.  At least one the announced capabilities MUST match

mutually.  If there is no single matching capability the reacting

node MUST act as if it does not implement DOIC and cease inserting

any DOIC related AVPs into any Diameter messages with this specific

reacting node.



is not clear.  Would the reporting node include the OC-Feature-Vector AVP in the answer only if there is at least one matching capability?



Because then they have found a way to exchange something that both ends

know how to handle it.



Mandating the reacting node to cease for all time inserting OC-Feature-Vector AVPs if it did not get back



There is an obvious typo. It should say:



policies.  At least one the announced capabilities MUST match

mutually.  If there is no single matching capability the reporting

node MUST act as if it does not implement DOIC and cease inserting

any DOIC related AVPs into any Diameter messages with this specific

reacting node.



- JOuni





at least one match is also not ok. The request might have been a realm-type request (i.e. without Destination Host) and the reacting node cannot control whether subsequent requests will take the same path to the same reporting node.

Even if the request contains a destination host the reacting node cannot know wether the reacting node's capabilities have been modified by the time a subsequent request is sent.

Proposal is to keep only the first sentence and delete the rest.



Ulrich





_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime















_______________________________________________

DiME mailing list

DiME@ietf.org<mailto:DiME@ietf.org>

https://www.ietf.org/mailman/listinfo/dime