Subject: [Dime] OVLI: comments to 4.1

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 5 Dec 2013 13:23:33 +0000

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"

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

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), 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.
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? 
Mandating the reacting node to cease for all time inserting OC-Feature-Vector AVPs if it did not get back 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

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 6 Dec 2013 12:17:00 +0200

> 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.

> 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.
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 6 Dec 2013 13:03:28 +0000

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.

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

Best regards
Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Friday, December 06, 2013 11:17 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.1

OK with me.

OK with me.

- JOuni

---

From: Ben Campbell <[email-masked]>
Date: Fri, 6 Dec 2013 15:45:10 -0600

On Dec 6, 2013, at 4:17 AM, Jouni Korhonen <[email-masked]> wrote:

[...]

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

Whether it's a timestamp, sequence number, or random number, we should describe the required uniqueness properties. (i.e. unique for that sender, unique across all senders, unique over a short period of time vs long period of time, etc.)

There may be other reasons to identify who sent the OC-Feature-Vector. Should we consider including the sender identity?

> Do not agree removing it.

I concur with Jouni. IIRC, the point of having a sequence number here was so that if a reacting-node chooses to send the feature vector in every request, the reacting node can easily determine if the contents have changed, and ignore it if not. But it might be reasonable to consider whether that saves enough work to make it worth the trouble.

[...]

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 9 Dec 2013 10:16:35 +0000

For the OC-Feature-Vector AVP I still think that there is no need for anything like sequence number or timestamp (for OC-OLR things are different).

Including the sender identity of the node that sent the OC-Feature-Vector is not needed and would add complexity.

Ben wrote:

"...the point of having a sequence number here was so that if a reacting-node chooses to send the feature vector in every request, the reacting node can easily determine if the contents have changed, and ignore it if not..."

However, an unchanged Feature-Vector must not be ignored. It is still valid and the receiving node must honor it. Of course it could instead honor an identical stored Feature-Vector, but this again adds unnecessary complexity ("check if the received feature vector has changed, if not take the stored feature vector otherwise take the received feature vector" rather than "always take the received feature vector").

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]] 
Sent: Friday, December 06, 2013 10:45 PM
To: Jouni Korhonen
Cc: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.1

[...]

[...]

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 9 Dec 2013 14:06:45 +0200

Folks,

Unless someone strongly disagrees, I'll submit the below changes into -01. That
is just renaming AVPs but as Ulrich says, the current definitions are misleading.

- Jouni

ps: I already made global change into my -01 copy so you need a very strong case
    for me to revert the changes back ;-)

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 9 Dec 2013 14:12:28 +0200

Ulrich,

> 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.

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

Ack. Fixed the missing 'of'.

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 9 Dec 2013 12:47:07 +0000

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:[email-masked]] 
Sent: Monday, December 09, 2013 1:12 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.1

Ulrich,

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 9 Dec 2013 14:55:20 +0200

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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 9 Dec 2013 13:13:06 +0000

There is a fundamental difference:
OLRs need to be stored, Feature-Vectors not.
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:[email-masked]] 
Sent: Monday, December 09, 2013 1:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.1

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 9 Dec 2013 15:24:32 +0200

> 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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 9 Dec 2013 14:43:33 +0000

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:[email-masked]] 
Sent: Monday, December 09, 2013 2:25 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.1

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Mon, 09 Dec 2013 09:56:03 -0600

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

---

From: Ben Campbell <[email-masked]>
Date: Mon, 9 Dec 2013 16:46:46 -0600

On Dec 9, 2013, at 9:56 AM, Steve Donovan <[email-masked]> 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:
> 
> If the reporting node is in overload then generate and append the OC-OLR AVPs.
> 
> If the sequence number is changed from the last version number received then 
> 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.

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 10 Dec 2013 10:40:56 +0200

> 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 informatio…

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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 10 Dec 2013 09:28:27 +0000

Steve, Ben,

thank you for the clarification.
Its definitly worth pointing out what the intended (optional) use for the sequence number is.

Do you have any clarification for the use of Sequence-Number in OC-Feature-Vectors in answer messages? 

Ulrich

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 10 Dec 2013 10:41:30 +0000

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.

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?

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Tuesday, December 10, 2013 9:41 AM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.1

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 10 Dec 2013 13:31:58 +0200

> 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.

> 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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 10 Dec 2013 12:18:35 +0000

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Tuesday, December 10, 2013 12:32 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.1

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.

- Jouni

---

From: Jouni Korhonen <[email-masked]>
Date: Tue, 10 Dec 2013 23:46:20 +0200

Ulrich,

> [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…

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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 11 Dec 2013 07:34:44 +0000

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:[email-masked]] 
Sent: Tuesday, December 10, 2013 10:46 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.1

Ulrich,

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Wed, 11 Dec 2013 07:33:33 -0600

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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 12 Dec 2013 09:30:09 +0000

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:[email-masked]] On Behalf Of ext Steve Donovan
Sent: Wednesday, December 11, 2013 2:34 PM
To: [email-masked]
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

Jouni,

I do not agree.

Ulrich

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

Cc: [email-masked]<mailto:[email-masked]>

Ulrich,

On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]><mailto:[email-masked]> wrote:

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

Cc: [email-masked]<mailto:[email-masked]>

On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]><mailto:[email-masked]> wrote:

Hi Jouni,

- Jouni

Furthermore,

- Jouni

Ulrich

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

Cc: [email-masked]<mailto:[email-masked]>

On Dec 9, 2013, at 4:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]><mailto:[email-masked]> wrote:

consuming function.

can change at any time).

- Jouni

Ulrich

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

Cc: [email-masked]<mailto:[email-masked]>

On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]><mailto:[email-masked]> wrote:

- Jouni

Ulrich

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

Cc: [email-masked]<mailto:[email-masked]>

- Jouni

On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]><mailto:[email-masked]> wrote:

Ulrich

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

Cc: [email-masked]<mailto:[email-masked]>

Ulrich,

On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]><mailto:[email-masked]> wrote:

Hi Jouni,

With regard to 3)

With regard to 4)

- Jouni

Best regards

Ulrich

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

Cc: [email-masked]<mailto:[email-masked]>

On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]><mailto:[email-masked]> wrote:

Dear all,

OK with me.

OK with me.

seqnr.

4. The text

reacting node.

know how to handle it.

reacting node.

- JOuni

Ulrich

DiME mailing list

[email-masked]<mailto:[email-masked]>

DiME mailing list

[email-masked]<mailto:[email-masked]>

---

From: Steve Donovan <[email-masked]>
Date: Thu, 12 Dec 2013 07:55:12 -0600

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:[email-masked]] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Wednesday, December 11, 2013 2:34 PM
> *To:* [email-masked]
> *Subject:* Re: [Dime] OVLI: comments to 4.1
>
>  
>
> Ulrich,
>
> 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
>
>     Cc: [email-masked] <mailto:[email-masked]>
>
>     On Dec 10, 2013, at 2:18 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> <mailto:[email-masked]> wrote:
>
>      
>
>          
>
>          
>
>         Cc: [email-masked] <mailto:[email-masked]>
>
>         On Dec 10, 2013, at 12:41 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> <mailto:[email-masked]> wrote:
>
>          
>
>             Hi Jouni,
>
>              
>
>             Cc: [email-masked] <mailto:[email-masked]>
>
>             On Dec 9, 2013, at 4:43 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> <mailto:[email-masked]> wrote:
>
>              
>
>                 Cc: [email-masked] <mailto:[email-masked]>
>
>                 On Dec 9, 2013, at 3:13 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> <mailto:[email-masked]> wrote:
>
>                  
>
>                     Cc: [email-masked] <mailto:[email-masked]>
>
>                     On Dec 9, 2013, at 2:47 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> <mailto:[email-masked]> wrote:
>
>                      
>
>                         Cc: [email-masked] <mailto:[email-masked]>
>
>                         On Dec 6, 2013, at 3:03 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> <mailto:[email-masked]> wrote:
>
>                          
>
>                             Hi Jouni,
>
>                              
>
>                             Cc: [email-masked] <mailto:[email-masked]>
>
>                             On Dec 5, 2013, at 3:23 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> <mailto:[email-masked]> wrote:
>
>                              
>
>                                 Dear all,
>
>                                  
>
>                                 [email-masked] <mailto:[email-masked]>
>
>     [email-masked] <mailto:[email-masked]>
>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 12 Dec 2013 15:22:55 +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:[email-masked]]
Sent: Thursday, December 12, 2013 2:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
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

Ulrich

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

Ulrich,

Steve

Jouni,

I do not agree.

Ulrich

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

Ulrich,

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

Hi Jouni,

- Jouni

Furthermore,

- Jouni

Ulrich

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

consuming function.

can change at any time).

- Jouni

Ulrich

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

- Jouni

Ulrich

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

- Jouni

Ulrich

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

Ulrich,

Hi Jouni,

With regard to 3)

With regard to 4)

- Jouni

Best regards

Ulrich

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

Dear all,

OK with me.

OK with me.

seqnr.

4. The text

reacting node.

know how to handle it.

reacting node.

- JOuni

Ulrich

DiME mailing list

DiME mailing list

---

From: Steve Donovan <[email-masked]>
Date: Thu, 12 Dec 2013 09:33:31 -0600

Ulrich,

Thanks for the correction -- obviously typed pre coffee this morning.

The tradeoff is requiring processing on every request versus maintaining
state to allow avoiding that processing on 99.99% of requests.

We should let individual implementers make the decision on which
approach they prefer.

Steve

On 12/12/13 9:22 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> 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:[email-masked]]
> *Sent:* Thursday, December 12, 2013 2:55 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
> 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.
>
>     *From:*DiME [mailto:[email-masked]] *On Behalf Of *ext
>     Steve Donovan
>     *To:* [email-masked] <mailto:[email-masked]>
>     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. 
>
>     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
>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 12 Dec 2013 16:02:44 +0000

Steve,
ok, but then its only fair to let individual implementers (of reacting nodes) make the decision whether or not to spend the effort of include a sequence number in the OC-Supported-Features (i.e. make the sequence number optional).

Isn't the situation similar to the proposal to introduce Ongoing-Throttling-Information mandatorily in requests and let implementers of reporting nodes decide whether they want to make use of this information?

Ulrich

See also inline

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Thursday, December 12, 2013 4:34 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.1

Ulrich,

The tradeoff is requiring processing on every request versus maintaining state to allow avoiding that processing on 99.99% of requests.
[Wiehe, Ulrich (NSN - DE/Munich)] The tradeoff is between a) checking the Supported_Features in every request and know what to do, and b) checking the sequence number in every request, looking up a database and then (in 99.99% of cases) know what to do.

We should let individual implementers make the decision on which approach they prefer.

Steve

Ulrich

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Thursday, December 12, 2013 2:55 PM
To: Wiehe, Ulrich (NSN - DE/Munich); [email-masked]<mailto:[email-masked]>
Subject: Re: [Dime] OVLI: comments to 4.1

Ulrich,

Steve

Ulrich

Ulrich,

Steve

Jouni,

I do not agree.

Ulrich

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

Ulrich,

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

Hi Jouni,

- Jouni

Furthermore,

- Jouni

Ulrich

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

consuming function.

can change at any time).

- Jouni

Ulrich

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

- Jouni

Ulrich

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

- Jouni

Ulrich

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

Ulrich,

Hi Jouni,

With regard to 3)

With regard to 4)

- Jouni

Best regards

Ulrich

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

Dear all,

OK with me.

OK with me.

seqnr.

4. The text

reacting node.

know how to handle it.

reacting node.

- JOuni

Ulrich

DiME mailing list

DiME mailing list

---

From: Jouni Korhonen <[email-masked]>
Date: Fri, 13 Dec 2013 15:33:05 +0200

> ok, but then its only fair to let individual implementers (of reacting nodes) make the decision whether or not to spend the effort of include a sequence number in the OC-Supported-Features (i.e. ma…

Having a mandatory to send but optional to process AVP would fit here.
That would not be optional in a Diameter CCF point of view but text
saying on the receiver side "MAY process seqno.." or "SHOULD process
seqno..". Just avoiding MUST should do.

- JOuni

>  
> Isn’t the situation similar to the proposal to introduce Ongoing-Throttling-Information mandatorily in requests and let implementers of reporting nodes decide whether they want to make use of this information?
>  
> Ulrich
>  
> See also inline
>  
>  
> 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
>  
>  
> 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: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 16 Dec 2013 10:22:58 +0000

Then let's do the same way with Ongoing-Throttling-Information.

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Friday, December 13, 2013 2:33 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Steve Donovan; [email-masked]
Subject: Re: [Dime] OVLI: comments to 4.1

- JOuni

---

From: Ben Campbell <[email-masked]>
Date: Mon, 16 Dec 2013 15:08:54 -0600

> ok, but then its only fair to let individual implementers (of reacting nodes) make the decision whether or not to spend the effort of include a sequence number in the OC-Supported-Features (i.e. ma…

I don't think that's the sort of fairness the requirements contemplated :-)

Reacting Nodes would only need to calculate a new sequence number if it's capabilities change. That won't happen often. Also, it's trivially easy to calculate a new sequence number. If the reacting node does not include one, the reporting node is forced to re-check the capabilities on every single Diameter request that includes one. (Which will likely be "all requests".)

> Isn’t the situation similar to the proposal to introduce Ongoing-Throttling-Information mandatorily in requests and let implementers of reporting nodes decide whether they want to make use of this…

No, I don't think it is. That only matters in overload situations. This applies to every single request all the time.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 16 Dec 2013 15:10:10 -0600

> seqno..". Just avoiding MUST should do.

+1

---

From: Ben Campbell <[email-masked]>
Date: Mon, 16 Dec 2013 15:10:39 -0600

> Then let's do the same way with Ongoing-Throttling-Information.

-1 (see my comment to earlier email.)