Subject: Re: [Dime] Issue#30 status

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 3 Mar 2014 10:50:34 +0000

Jouni,

Is this your proposal or your decision?

Anyway, what is the expected behaviour of the reacting node (that supports only OLR_DEFAULT_ALGO) when receiving an answer that contains
a) OLR but no Supported-Features
b) Supported Features but no OLR
c) OLR and Supported Features

Is the information received in Supported-Features in the answer something that needs to be taken into account when sending subsequent requests (i.e. do less proactive throttling), or something that needs to be taken into account when interpreting the OLR received in the same answer? 

What if the received Supported-Features in the answer  does not indicate OLR_DEFAULT_ALGO?
What if the received Supported-Features in the answer indicates support of something different than OLR_DEFAULT_ALGO?
What if the received Supported Features in the answer indicates support of OLR_DEFAULT_ALGO and support of something else?

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Friday, February 28, 2014 2:49 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; [email-masked] list
Subject: Re: [Dime] Issue#30 status

<as a chair>

Right. We are going back and forth and continue to do that as long
as none of these moving parts can be nailed down. My proposal here
is that we simply agree now that OC-Supported-Features is in every
answer message. Period. Get one corner nailed down.

The rest of the fixing inconsistencies and missing/excess parts
listed below then need to be done according to the above decision.

- JOuni

On Feb 28, 2014, at 9:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> wrote:

> Anders,
> 
> Yes, if we conclude that there is a requirement for OC-Supported-Features to be sent in answers, then it should be included in every answer. However, I still don't see that requirement. In addition we would need some text specifying the expected behaviour of the reacting node when receiving OC-Supported-Features in an answer, keeping in mind that the reacting node cannot know whether it was the server or an agent that inserted the OC-Supported-Feature, and whether or not a subsequent request will be routed via that node.
> 
> Ulrich
> 
> -----Original Message-----
> From: DiME [mailto:[email-masked]] On Behalf Of ext Askerup, Anders
> Sent: Thursday, February 27, 2014 6:14 PM
> To: Ben Campbell; Steve Donovan
> Cc: [email-masked] list
> Subject: Re: [Dime] Issue#30 status
> 
> I also agree that including OC-Supported-Features in every answer is preferable. In addition to mirroring Requests, it is in-line with how Supported-Features are managed in at least some 3GPP interfaces as well.
> 
> /Anders
> 
> -----Original Message-----
> From: DiME [mailto:[email-masked]] On Behalf Of Ben Campbell
> Sent: Wednesday, February 26, 2014 9:19 AM
> To: Steve Donovan
> Cc: [email-masked] list
> Subject: Re: [Dime] Issue#30 status
> 
> 
> On Feb 26, 2014, at 9:14 AM, Steve Donovan <[email-masked]> wrote:
> 
>> SRD> We don't have consensus yet, but if we agree on the need for reacting nodes to know whether there is support for DOIC in the Diameter network then I think the requirement would be similar to how we are handling overload reports.  The reporting node MUST ensure that all reacting nodes receive the OC-Supported-Features AVP.  This can be done by including the AVP in all answer messages or it can be done by remembering to whom the AVP has been sent.
> 
> Given the trivial nature of sending and reading OC-Supported-Features, I think we should put it in every answer. This mirrors the way we handle it in requests.
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Jouni Korhonen <[email-masked]>
Date: Mon, 3 Mar 2014 11:21:15 +0000

> as none of these moving parts can be nailed down. My proposal here
                                                    ^^^^^^^^^^^^
> a) OLR but no Supported-Features

Ehh.. if we agree that OC-Suppoted-Feature is in every answer message
this would be an error case (misbehaving reporting node). My proposal
would be reporting node to discard the OC-OLR.

> b) Supported Features but no OLR

Reporting node has nothing to report except that it states it supports
DOIC. No chance in the current state, if there is one.

> Is the information received in Supported-Features in the answer something that needs to be taken into account when sending subsequent requests (i.e. do less proactive throttling), or something that…

Depends on the abatement algorithm or other future features. In the
context of this I-D there is no such dependency since we got only
one algorithm which is simple request-reply nature.

> What if the received Supported-Features in the answer  does not indicate OLR_DEFAULT_ALGO?

Then the OC-OLR must include abatement information that matches with the 
algorithm/feature indicated in the OC-Supported-Features. Sending an empty
OC-Supported-Features in not allowed.

> What if the received Supported-Features in the answer indicates support of something different than OLR_DEFAULT_ALGO?

Same as above. It is a valid use case (for future deployments) that a
network absolutely wants to use some other algorithm than the default.
Then announcing the default is no use. Our protocol needs to be flexible
enough to allow such policy decision.

> What if the received Supported Features in the answer indicates support of OLR_DEFAULT_ALGO and support of something else?

This is something that is open but as I tried to drive at the beginning
the OC-Supported-Features in an answer names a single selected abatement
algorithm. 

- Jouni

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 3 Mar 2014 12:51:55 +0000

Thank you for the clarification.
It seems the proposed principles are:

1. Reporting nodes MUST always include an OC-Supported-Features AVP to an answer message that corresponds to a request which contained an OC-Supported-Features AVP.

2. Reacting nodes MUST ignore an OC-OLR AVP received in an answer message when
	2a) There was no OC-Supported-Features AVP in the answer
	2b) The OC-Supported-Features AVP in the answer indicated support of more than one supported feature
	2c) The OC-Supported-Features AVP in the answer indicated support of less than one supported feature
	2d) The OC-Supported-Features AVP in the answer indicated support of exactly one feature, but that one is not supported by the reacting node.

3. Reacting nodes MUST interpret a received OC-OLR in the context of the selected feature as received within the OC-Supported-Features AVP. 

4. Reacting nodes receiving neither OC-OLR nor OC-Supported-Features in answers (from a destination) may or may not do proactive throttling towards that destination. 

5. When receiving an answer that does not contain an OC-OLR, the reacting node can safely ignore an OC-Supported-Features AVP (as there is no OC-OLR which needs to be interpreted/ignored based on information received in OC-Supported-Features).

Is this agreeable?

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Monday, March 03, 2014 12:21 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; [email-masked] list
Subject: Re: [Dime] Issue#30 status

                                                    ^^^^^^^^^^^^

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Mon, 03 Mar 2014 13:25:47 +0000

Ulrich,

I think you mean "abatement algorithm" below when you say feature.

There will be cases when it is valid to indicate support multiple 
features.  Support for the loss algorithm and agent overload is an 
example.  It is not valid for the reporting node to indicate support for 
two abatement algorithms.

See more below.

Steve

> 	2d) The OC-Supported-Features AVP in the answer indicated support of exactly one feature, but that one is not supported by the reacting node.
SRD> The above three should say abatement algorithm instead of feature.
> 5. When receiving an answer that does not contain an OC-OLR, the reacting node can safely ignore an OC-Supported-Features AVP (as there is no OC-OLR which needs to be interpreted/ignored based on i…
SRD> This should be modified with a note saying that this can and likely 
will change when the protocol is extended.  Maybe this would be in an 
extensibility section.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 3 Mar 2014 13:30:44 +0000

+1. 

Also, we don't need to include a lot of normative MUSTS around handling every way a peer might behave badly, and we shouldn't force implementations to act as "protocol police" for their peers.  2119 language should be used sparingly, focusing on places where we think implementors are likely to make bad choices without guidance. 

On Mar 3, 2014, at 1:25 PM, Steve Donovan <[email-masked]> wrote:

> There will be cases when it is valid to indicate support multiple features.  Support for the loss algorithm and agent overload is an example.  It is not valid for the reporting node to indicate support for two abatement algorithms.
> 
> See more below.
> 
> Steve
> 
> SRD> This should be modified with a note saying that this can and likely will change when the protocol is extended.  Maybe this would be in an extensibility section.
>> 
>> Is this agreeable?
>> 
>> Ulrich
>>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 3 Mar 2014 13:56:35 +0000

Steve,

but

(ad 2.) how would (implementers of) the reacting node know whether e.g. bit 5 of the OC-Feature-Vector will be allocated to an "abatement algorithm" or to something else?

Ad 5. Would it be ok to say:
5. When receiving an answer that does not contain an OC-OLR, the reacting node which supports only OLR_DEFAULT_ALGO and no other feature can safely ignore an OC-Supported-Features AVP (as there is no OC-OLR which needs to be interpreted/ignored based on information received in OC-Supported-Features). This may be different for reacting nodes which support other features than just OLR_DEFAULT_ALGO.

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]] 
Sent: Monday, March 03, 2014 2:26 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Jouni Korhonen
Cc: ext Askerup, Anders; Ben Campbell; [email-masked] list
Subject: Re: [Dime] Issue#30 status

Ulrich,

See more below.

Steve

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Mon, 3 Mar 2014 17:42:46 +0000

Dear Ulrich, all,

I think number 4 can be removed from the list of principles, this does not provide any information as such, but just a possibility that is equally open without this principle in the list. Don't you think?
Cheers
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: lunes, 03 de marzo de 2014 13:52
To: ext Jouni Korhonen
Cc: Ben Campbell; [email-masked] list
Subject: Re: [Dime] Issue#30 status

Is this agreeable?

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Monday, March 03, 2014 12:21 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; [email-masked] list
Subject: Re: [Dime] Issue#30 status

                                                    ^^^^^^^^^^^^

- Jouni

---

From: Steve Donovan <[email-masked]>
Date: Mon, 03 Mar 2014 18:21:54 +0000

Inline...

> (ad 2.) how would (implementers of) the reacting node know whether e.g. bit 5 of the OC-Feature-Vector will be allocated to an "abatement algorithm" or to something else?
SRD> A node that doesn't understand the meaning of a bit presumably
should ignore that bit.  In addition, I believe we have it defined that
the reporting node selects from the abatement algorithms in the
OC-Supported-Features AVP received from the reacting node. 
> 5. When receiving an answer that does not contain an OC-OLR, the reacting node which supports only OLR_DEFAULT_ALGO and no other feature can safely ignore an OC-Supported-Features AVP (as there is…
SRD> I ok with this if we remove the parenthetical statement.

---

From: Ben Campbell <[email-masked]>
Date: Mon, 3 Mar 2014 18:28:12 +0000

On Mar 3, 2014, at 6:21 PM, Steve Donovan <[email-masked]> wrote:

> SRD> A node that doesn't understand the meaning of a bit presumably should ignore that bit.  In addition, I believe we have it defined that the reporting node selects from the abatement algorithms in the OC-Supported-Features AVP received from the reacting node.  

This. 

Can we assume that to be true for all "features" that can be identified in OC-Supported-Features?

> SRD> I ok with this if we remove the parenthetical statement. 

I'm not sure what the point of saying that would be, at least with normative language; it's just a statement of fact. What behavior are we trying to avoid by saying the reacting node can ignore it?

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 4 Mar 2014 11:22:18 +0000

Steve,
I'm trying to understand the principles. Is it so that we have two usecases for OC-Supported-Features AVP in an answer message:
a) if the answer does not contain an OLR then OC-Supported-Features contains all features the reporting node supports (or all features the reporting node and the reacting node commonly support (what would be the difference from the reacting node's point of view?))
b) if the answer contains an OLR then the OC-Supported-Features contains the selected features (selected from the set of features advertised in the request); any inconsistency (e.g. more than one abatement alogorithm; something is selected that was not advertised) would result in ignoring the OLR.

For b), if the OLR is a replay, I guess the selected features in OC-Supported-Features must also not change (and should be ignored together with the OLR).

Ulrich

Sent: Monday, March 03, 2014 7:22 PM

Inline...

Steve,

but

Ulrich

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

Cc: ext Askerup, Anders; Ben Campbell; [email-masked]<mailto:[email-masked]> list

Ulrich,

See more below.

Steve

extensibility section.

Is this agreeable?

Ulrich

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

Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; [email-masked]<mailto:[email-masked]> list

On Mar 3, 2014, at 10:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]><mailto:[email-masked]> wrote:

Jouni,

                                                     ^^^^^^^^^^^^

algorithm.

- Jouni

Ulrich

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

Cc: ext Askerup, Anders; Ben Campbell; Steve Donovan; [email-masked]<mailto:[email-masked]> list

<as a chair>

- JOuni

On Feb 28, 2014, at 9:50 AM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]><mailto:[email-masked]> wrote:

Anders,

Ulrich

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

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

/Anders

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

To: Steve Donovan

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

On Feb 26, 2014, at 9:14 AM, Steve Donovan <[email-masked]><mailto:[email-masked]> wrote:

DiME mailing list

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

DiME mailing list

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

DiME mailing list

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

---

From: Ben Campbell <[email-masked]>
Date: Tue, 4 Mar 2014 11:33:51 +0000

On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> wrote:

> Steve,
> I’m trying to understand the principles. Is it so that we have two usecases for OC-Supported-Features AVP in an answer message:
> a) if the answer does not contain an OLR then OC-Supported-Features contains all features the reporting node supports (or all features the reporting node and the reacting node commonly support (what would be the difference from the reacting node’s point of view?))

IMO, OC-Supported-Features should be treated as a) in all cases. If we need information about the specific selections made for a particular OLR, that info belongs in the OLR.

> For b), if the OLR is a replay, I guess the selected features in OC-Supported-Features must also not change (and should be ignored together with the OLR).

That would be mostly irrelevant if the we put OLR selections in the OLR, so long as the generally advertised features in OC-Supported-Features do not change in a way that makes the OLR no longer valid.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 4 Mar 2014 11:43:32 +0000

I agree with Ben

But then again: which purpose does OC-Supported-Features I answer serve?
Ulrich

---

From: Steve Donovan <[email-masked]>
Date: Tue, 04 Mar 2014 11:53:21 +0000

It serves to tell the reacting node that the reporting node supports
DOIC, the features that the two nodes have in common and the abatement
algorithm that the reporting node will be using.

I agree that capability exchange should be kept separate from overload
reports.  We don't, however, have consensus on this point.

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 4 Mar 2014 12:06:09 +0000

From: ext Steve Donovan [mailto:[email-masked]]
Sent: Tuesday, March 04, 2014 12:53 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: ext Jouni Korhonen; ext Askerup, Anders; [email-masked] list
Subject: Re: [Dime] Issue#30 status

It serves to tell the reacting node that the reporting node supports DOIC, the features that the two nodes have in common and the abatement algorithm that the reporting node will be using. <Ulrich>...so that the the reacting node can - based on that information - do what?</Ulrich>

I agree that capability exchange should be kept separate from overload reports.  We don't, however, have consensus on this point.<Ulrich>Is it only Jouni who wants this  dependency?</Ulrich>

Steve

I agree with Ben

Ulrich

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

Cc: ext Steve Donovan; ext Jouni Korhonen; ext Askerup, Anders; [email-masked]<mailto:[email-masked]> list

On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]><mailto:[email-masked]> wrote:

Steve,

Ulrich

---

From: Steve Donovan <[email-masked]>
Date: Tue, 04 Mar 2014 13:19:37 +0000

Ulrich,

We've already discussed this.

I understand that you don't think that the OC-Supported-Features AVP
should be required in all answer messages.

Others of us think that it should be.  We can't make progress if we have
to re-debate every point multiple times.

I suggest that we follow Jouni's guidance made a few emails back and
move on.

Steve

On 3/4/14 12:06 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
>  
>
>  
>
> *From:*ext Steve Donovan [mailto:[email-masked]]
> *Sent:* Tuesday, March 04, 2014 12:53 PM
> *To:* Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
> *Cc:* ext Jouni Korhonen; ext Askerup, Anders; [email-masked] list
> *Subject:* Re: [Dime] Issue#30 status
>
>  
>
> algorithm that the reporting node will be using.*/<Ulrich>...so that
> the the reacting node can -- based on that information -- do
> what?</Ulrich>/*
>
> reports.  We don't, however, have consensus on this point.*/<Ulrich>Is
> it only Jouni who wants this  dependency?</Ulrich>/*
>
> Steve
>
>     Cc: ext Steve Donovan; ext Jouni Korhonen; ext Askerup, Anders; [email-masked] <mailto:[email-masked]> list
>
>     On Mar 4, 2014, at 11:22 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> <mailto:[email-masked]> wrote:
>
>      
>
>         Steve,
>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 4 Mar 2014 14:58:18 +0000

Steve,
I m trying to progress this.

As you say we don't have consensus on the question  whether capability exchange should be kept separate from overload reports or not.

Let's focus on this issue.

Once this issue is resolved we will know whether
a) OC-Supported-Features conveys the selected features and is used together with the OLR to interprete the meaning of the OLR, or
b) OC-Supported-Features conveys the supported features (and would be sent for information, the reason being just because people decided so)

Ulrich

Sent: Tuesday, March 04, 2014 2:20 PM

Ulrich,

I understand that you don't think that the OC-Supported-Features AVP should be required in all answer messages.

Others of us think that it should be.  We can't make progress if we have to re-debate every point multiple times.

I suggest that we follow Jouni's guidance made a few emails back and move on.

Steve

Cc: ext Jouni Korhonen; ext Askerup, Anders; [email-masked]<mailto:[email-masked]> list

Steve

I agree with Ben

Ulrich

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

Steve,

Ulrich

---

From: Steve Donovan <[email-masked]>
Date: Tue, 04 Mar 2014 15:43:44 +0000

Ulrich,

I don't see that the two questions overlap.  If we go with a) then the
OC-Supported-Features could only be required in answers with an OC-OLR
AVP.  This by itself would not be the reason for OC-Supported-Features
to be included in all messages, which is the proposal.

In addition, the reason is not "just because people decided too".  The
reasons, as previously discussed, are:

1) To be consistent with the pattern already established for feature
capabilities negotiation.
2) As part of the extensibility design, as we know of cases where
reacting nodes will need to understand the abatement algorithm in advance.
3) As a tool for reacting nodes to handle situations where there are no
DOIC capable nodes.

I believe there is also fourth reason I've come across as I have been
thinking about the definition of overload endpoints.

The case where some servers support DOIC and some servers do not support
DOIC.  In this scenario, agents will be expected to take on the roll of
the reporting node for non supporting servers.  For the servers that
support DOIC the server will be the reporting node.  The agent needs the
OC-Supported-Features AVP to be able to determine which set of servers
support DOIC and which do not.

Steve

On 3/4/14 2:58 PM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> As you say we don't have consensus on the question  whether capability
> exchange should be kept separate from overload reports or not.
>
>  
>
> a) OC-Supported-Features conveys the selected features and is used
> together with the OLR to interprete the meaning of the OLR, or
>
> b) OC-Supported-Features conveys the supported features (and would be
> sent for information, the reason being just because people decided so)
>
>  
>
> Ulrich
>
>  
>
>  
>
>  
>
>  
>
>  
>
> *Sent:* Tuesday, March 04, 2014 2:20 PM
> Others of us think that it should be.  We can't make progress if we
> have to re-debate every point multiple times.
>
>     *Cc:* ext Jouni Korhonen; ext Askerup, Anders; [email-masked]
>     <mailto:[email-masked]> list
>     It serves to tell the reacting node that the reporting node
>     supports DOIC, the features that the two nodes have in common and
>     the abatement algorithm that the reporting node will be
>     using.*/<Ulrich>...so that the the reacting node can -- based on
>     that information -- do what?</Ulrich>/*
>
>     I agree that capability exchange should be kept separate from
>     overload reports.  We don't, however, have consensus on this
>     point.*/<Ulrich>Is it only Jouni who wants this 
>     dependency?</Ulrich>/*
>
>     Steve
>

---

From: <[email-masked]>
Date: Tue, 4 Mar 2014 17:56:05 +0000

If (i said "if") I can correctly remember my own statement, I'm ok with OC-Supported-Features AVP in every answer.

However, it is not so clear what would its value, depending on the presence of the OLR in the answer... Always all the supported algos or the selected algo(s) when one OLR is present?

Lionel

De : DiME [mailto:[email-masked]] De la part de Steve Donovan
Envoyé : mardi 4 mars 2014 16:44
À : Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc : [email-masked] list
Objet : Re: [Dime] Issue#30 status

Ulrich,

I don't see that the two questions overlap.  If we go with a) then the OC-Supported-Features could only be required in answers with an OC-OLR AVP.  This by itself would not be the reason for OC-Supported-Features to be included in all messages, which is the proposal.

In addition, the reason is not "just because people decided too".  The reasons, as previously discussed, are:

1) To be consistent with the pattern already established for feature capabilities negotiation.
2) As part of the extensibility design, as we know of cases where reacting nodes will need to understand the abatement algorithm in advance.
3) As a tool for reacting nodes to handle situations where there are no DOIC capable nodes.

I believe there is also fourth reason I've come across as I have been thinking about the definition of overload endpoints.

The case where some servers support DOIC and some servers do not support DOIC.  In this scenario, agents will be expected to take on the roll of the reporting node for non supporting servers.  For the servers that support DOIC the server will be the reporting node.  The agent needs the OC-Supported-Features AVP to be able to determine which set of servers support DOIC and which do not.

Steve

Ulrich

Ulrich,

Steve

Steve

I agree with Ben

Ulrich

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

Steve,

Ulrich

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 5 Mar 2014 08:33:48 +0000

So. are we OK to agree and close the issue #30 for the part that was
proposed here: http://www.ietf.org/mail-archive/web/dime/current/msg06998.html
i.e. OC-Supported-Features is in every answer message? I am not sure anymore
since the discussion got exploded again to multiple directions.

Yes or yes? ;-)

If yes, we can close issue #30, document the conclusion and the changed text
snippets into the issue tracker, and then concentrate tearing apart the rest
of the functionality and implications based on the above decision in another
issue and thread?

- Jouni

On Mar 4, 2014, at 2:58 PM, "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]> wrote:

> As you say we don’t have consensus on the question  whether capability exchange should be kept separate from overload reports or not.
>  
> Let’s focus on this issue.
>  
> It serves to tell the reacting node that the reporting node supports DOIC, the features that the two nodes have in common and the abatement algorithm that the reporting node will be using. <Ulrich>…so that the the reacting node can – based on that information – do what?</Ulrich>
>

---

From: Ben Campbell <[email-masked]>
Date: Wed, 5 Mar 2014 09:14:38 +0000

> since the discussion got exploded again to multiple directions.

Yes for me.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 05 Mar 2014 09:54:06 +0000

Yes and yes for me.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 5 Mar 2014 09:55:49 +0000

Jouni,

I would like to see the complete picture.
There seems to be a majority in favour of the following:

2. OC-Supported-Features in answer messages indicate all features the reporting node supports (NOT all featues the reporting node and the reacting node commonly support; NOT the selected features selected by the reporting node out of the advertized features supported by the reacting node). The selected feature(s) would be somehow implicitly or explicitly part of the OC-OLR.

3. When receiving an answer, the reacting node, which supports only OLR_DEFAULT_ALGO and no other feature, can safely ignore the OC-Supported-Features AVP. This may be different for reacting nodes which support other features than just OLR_DEFAULT_ALGO.

Is this agreeable?
 
In order to make progress I'm ok to agree on this, but especially on 1. my agreement is "although I think there is no good reason"; other people may agree "because they think there is good reason". We don't need to re-discuss the reason.

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Wednesday, March 05, 2014 9:34 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; ext Ben Campbell; ext Askerup, Anders; [email-masked] list
Subject: Re: [Dime] Issue#30 status

Yes or yes? ;-)

- Jouni

---

From: <[email-masked]>
Date: Wed, 5 Mar 2014 09:58:51 +0000

ok

-----Message d'origine-----
De : DiME [mailto:[email-masked]] De la part de Wiehe, Ulrich (NSN - DE/Munich)
Envoyé : mercredi 5 mars 2014 10:56
À : ext Jouni Korhonen; ext Steve Donovan; ext Ben Campbell; ext Askerup, Anders; [email-masked] list
Objet : Re: [Dime] Issue#30 status

Jouni,

Is this agreeable?

Ulrich

-----Original Message-----
From: ext Jouni Korhonen [mailto:[email-masked]] 
Sent: Wednesday, March 05, 2014 9:34 AM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; ext Ben Campbell; ext Askerup, Anders; [email-masked] list
Subject: Re: [Dime] Issue#30 status

Yes or yes? ;-)

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Wed, 5 Mar 2014 10:03:12 +0000

> 1. Reporting nodes MUST always include an OC-Supported-Features AVP to an answer message that corresponds to a request which contained an OC-Supported-Features AVP. 

+1

> 2. OC-Supported-Features in answer messages indicate all features the reporting node supports (NOT all featues the reporting node and the reacting node commonly support; NOT the selected features s…

I've got mixed feelings on whether the OC-Supported-Features would represent everything the answerer supports, everything the answerer supports in common with the requestor, or everything the answerer actually might do.

I concur that any indication of what features are used in any particular OLR belong in the OLR. I think the question of how is orthogonal to this particular discussion.

> 3. When receiving an answer, the reacting node, which supports only OLR_DEFAULT_ALGO and no other feature, can safely ignore the OC-Supported-Features AVP. This may be different for reacting nodes…

I'm not comfortable asserting that. At a minimum, the receiver probably (lower case) should not ignore the fact that the OC-Supported-Features AVP is present or not present. But if it really turns out to be irrelevant to a particular reacting node implementation, then it's irrelevant. But that's implementation specific.

And in general, we should not use normative language to state observations of fact.  Stating that you can ignore an OC-Supported-Features that does happens not to constrain your behavior sounds like an observation. It might be okay to put it in a parenthetical (i.e. indented) note.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 05 Mar 2014 10:32:29 +0000

Ulrich,

Please see comments inline.

Steve

> 1. Reporting nodes MUST always include an OC-Supported-Features AVP to an answer message that corresponds to a request which contained an OC-Supported-Features AVP. 
SRD> Agreed.
> 2. OC-Supported-Features in answer messages indicate all features the reporting node supports (NOT all featues the reporting node and the reacting node commonly support; NOT the selected features s…
SRD> There is an advantage for the reporting node indicating which
abatement algorithm will be used if overload happens.  Assume the
reporting node supports both loss and rate, for instance, and assume
rate requires the client keep track of what has been sent prior to the
overload report to handle the overload report.

SRD> If the reporting node returns an indication that it supports both
loss and rate then the client will be forced to be prepared for a rate
report.  If the reporting node returns an indication that it will be
using loss then the client can avoid that work.
> 3. When receiving an answer, the reacting node, which supports only OLR_DEFAULT_ALGO and no other feature, can safely ignore the OC-Supported-Features AVP. This may be different for reacting nodes…
SRD> I agree with this statement and I also agree with Ben that this
should be included as an indented note.

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 5 Mar 2014 10:37:17 +0000

> 1. Reporting nodes MUST always include an OC-Supported-Features AVP to an answer message that corresponds to a request which contained an OC-Supported-Features AVP. 

Agree on 1). And this I want to close.

> 2. OC-Supported-Features in answer messages indicate all features the reporting node supports (NOT all featues the reporting node and the reacting node commonly support; NOT the selected features s…

This 2) I still do not agree because I want to understand the ground reasons and implications for behaviour implied by 2). And this I want to discuss separately from above 1) agreement.

> 3. When receiving an answer, the reacting node, which supports only OLR_DEFAULT_ALGO and no other feature, can safely ignore the OC-Supported-Features AVP. This may be different for reacting nodes…

Agree on 3). But this is IMHO again separate from 1) decision.

- Jouni

---

From: Ben Campbell <[email-masked]>
Date: Wed, 5 Mar 2014 10:38:20 +0000

On Mar 5, 2014, at 10:32 AM, Steve Donovan <[email-masked]> wrote:

> SRD> There is an advantage for the reporting node indicating which abatement algorithm will be used if overload happens.  Assume the reporting node supports both loss and rate, for instance, and assume rate requires the client keep track of what has been sent prior to the overload report to handle the overload report.
> 
> SRD> If the reporting node returns an indication that it supports both loss and rate then the client will be forced to be prepared for a rate report.  If the reporting node returns an indication that it will be using loss then the client can avoid that work.
> 

That supports the idea of OC-Supported-Features in an answer indicating the algorithms that the reporting node reasonably might use with the particular reacting node, so that the reacting node can be prepared to invoke potentially stateful algorithms. OTOH, would you treat features that are different from algorithms the same?

Have we reached any conclusion on whether a reporting node is able to change algorithms?

---

From: Ben Campbell <[email-masked]>
Date: Wed, 5 Mar 2014 10:40:05 +0000

> Agree on 3). But this is IMHO again separate from 1) decision.

I agree it is separate from the decision whether to require OC-S-F in each response. In fact, none of the conversations on point 1 or 2 seem to change that.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 5 Mar 2014 11:01:18 +0000

> I agree it is separate from the decision whether to require OC-S-F in each response. In fact, none of the conversations on point 1 or 2 seem to change that.

Oops, I mean to say conversations on points 2 or 3.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 05 Mar 2014 11:09:59 +0000

> That supports the idea of OC-Supported-Features in an answer indicating the algorithms that the reporting node reasonably might use with the particular reacting node, so that the reacting node can…
SRD> I think it should be up to the definition of the feature to define
what the reporting node sends in response to an advertisement of that
feature.
> Have we reached any conclusion on whether a reporting node is able to change algorithms?
SRD> I don't think we have.  I would propose that a reporting node
cannot change algorithms during an overload occurrence.  In other words,
a report for algorithm foo cannot be sent if there is an active report
for type bar.  We should probably go as far as to say that the reacting
node should ignore an OLR that specifies an algorithm different then the
algorithm for a valid OLR.

SRD> It should also be possible for a reporting node to use the loss
algorithm for one occurrence of overload and then use rate for the next
occurrence of overload.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 5 Mar 2014 14:37:26 +0000

Let me try again.

We agree that we want it although we don't know what it is and how it is used.

I would like to focus first on DOIC nodes that support just OLR_DEFAULT_ALGO  but no other feature:

A reporting node (that supports  OLR_DEFAULT_ALGO but no other feature) when receiving are request that
a)  contains an OC-Supported-Features AVP MUST include  an OC-Supported-Feature-AVP indicating support of OLR_DEFAULT_ALGO (but not support of any other feature) in the corresponding answer;
b) contains no OC-Supported-Features MUST NOT include an OC-Supported-Features-AVP in the corresponding answer.

For a reacting node (that supports  OLR_DEFAULT_ALGO but no other feature) we don't have a requirement to behave differently based on the presence/absence of an OC-Supported-Features AVP received in an answer, so this AVP may simply be ignored by the reacting node; (of course the reacting node may do some implementation specific differentiation, but that is out of scope).

When it comes to other DOIC nodes (i.e. DOIC nodes  that are supporting at least one feature different from   OLR_DEFAULT_ALGO) let me propose not to describe those node's behaviour in draft-ietf-dime-ovli  .  We should leave that to the I.D. that introduces the other feature.  

Ulrich