Re: [Dime] OVLI: comments to 4.1

[Steve Donovan <[e-mail]>]

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.

Regards,

Steve

On 12/9/13 8:43 AM, Wiehe, Ulrich (NSN - DE/Munich) 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.
>
> Ulrich
>
> -----Original Message-----
> From: ext Jouni Korhonen [mailto:[e-mail]] 
> Sent: Monday, December 09, 2013 2:25 PM
> To: Wiehe, Ulrich (NSN - DE/Munich)
> Cc: [e-mail]
> Subject: Re: [Dime] OVLI: comments to 4.1
>
>
> On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[e-mail]> 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:[e-mail]] 
>> Sent: Monday, December 09, 2013 1:55 PM
>> To: Wiehe, Ulrich (NSN - DE/Munich)
>> Cc: [e-mail]
>> 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)" <[e-mail]> 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:[e-mail]] 
>>> Sent: Monday, December 09, 2013 1:12 PM
>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>> Cc: [e-mail]
>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>
>>> Ulrich,
>>>
>>> On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[e-mail]> 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:[e-mail]] 
>>>> Sent: Friday, December 06, 2013 11:17 AM
>>>> To: Wiehe, Ulrich (NSN - DE/Munich)
>>>> Cc: [e-mail]
>>>> Subject: Re: [Dime] OVLI: comments to 4.1
>>>>
>>>>
>>>> On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[e-mail]> 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
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/dime
> _______________________________________________
> DiME mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dime
>