Subject: [Dime] Ben's comments on 4.3, third paragraph from end

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 15 Jan 2015 09:58:06 +0000

Ben wrote:
-- 4.3, third paragraph from end:

This still assumes that reporting nodes cannot change algorithms during overload. I thought we agreed to remove that. (The normative text is also still there--see later comment.)

<Ulrich> I don't understand. In my copy of -06 the third paragraph from end in 4.3 reads:
   Two types of overload abatement treatment are defined, diversion and
   throttling.  Reacting nodes are responsible for determining which
   treatment is appropriate for individual requests.
How does this text assume that reporting nodes cannot change algorithms during overload?

---

From: Steve Donovan <[email-masked]>
Date: Thu, 15 Jan 2015 07:14:13 -0600

I agree with Ulrich, I don't see the issue.

On 1/15/15 3:58 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> This still assumes that reporting nodes cannot change algorithms 
> during overload. I thought we agreed to remove that. (The normative 
> text is also still there--see later comment.)
> <Ulrich> I don’t understand. In my copy of -06 the third paragraph 
> from end in 4.3 reads:
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Ben Campbell <[email-masked]>
Date: Thu, 15 Jan 2015 09:18:58 -0600

Sorry, that was 4.2. 

> On Jan 15, 2015, at 7:14 AM, Steve Donovan <[email-masked]> wrote:
> 
>> <Ulrich> I don’t understand. In my copy of -06 the third paragraph from end in 4.3 reads:

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 16 Jan 2015 10:30:28 +0000

Ben

The Note at the beginning of 5.1 is about change of announced capabilities in reacting nodes, while the text in 4.2 (and 5.2.1.4) is about change of selected algorithm by reporting nodes.
I don't think the text in 4.2 (and 5.2.1.4) is totally wrong. Of course, if the reacting node changes the set of announced capabilities, the reporting node may change (or even need to  change) the selected algorithm. What is not allowed to be changed by the reporting node during an overload condition is the deterministic function that assignes to every set of commonly supported algorithms a distinct selected algorithm.

Ulrich

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of ext Ben Campbell
Sent: Thursday, January 15, 2015 4:19 PM
To: Steve Donovan
Cc: [email-masked]
Subject: Re: [Dime] Ben's comments on 4.3, third paragraph from end

Sorry, that was 4.2.

---

From: Steve Donovan <[email-masked]>
Date: Tue, 20 Jan 2015 12:27:22 -0600

I have removed the last sentence in the paragraph in question.  The 
before and after for the paragraph is as follows:

Before:

    Reporting nodes can change the overload abatement algorithm indicated
    in the OC-Feature-Vector AVP if the reporting node is not currently
    in an overload condition and sending overload reports.  The reporting
    node is not allowed to change the overload abatement algorithm while
    the reporting node is in an overload condition.

After:

    Reporting nodes can change the overload abatement algorithm indicated
    in the OC-Feature-Vector AVP if the reporting node is not currently
    in an overload condition and sending overload reports.

Ulrich,

I'm not sure I understand your point about the assignment of commonly 
supported algorithms.  Are you ok with this change?

Regards,

Steve

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Wed, 21 Jan 2015 10:06:35 +0000

Steve,
I'm not sure.
My understanding is:
1. Two answer messages (with same application id) sent by a reporting node while not in an overload condition can have different selected overload abatement algorithms in the OC-Feature-Vector AVP.
2. Two answer messages (with same application id) sent by a reporting node while in an (the same) overload condition must have the same selected overload abatement algorithm in the OC-Feature-Vector AVP if the two sets A and B are identical, where A is the intersection of the set of advertized algorithms received in the request that corresponds to the one answer message with the set of algorithms that are supported (at the time the one answer message is sent) by the reporting node, and B is the intersection of the set of advertized algorithms received in the request that corresponds to the other answer message with the set of algorithms that are supported (at the time the other answer message is sent) by the reporting node; And the set of algorithms supported by the reporting node must not change during an overload condition.

This ensures that reacting nodes, while not changing the set of advertized algorithms, will not receive a change of the selected algorithm during an overload condition (without the need for the reporting node to keep history data).

Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]] 
Sent: Tuesday, January 20, 2015 7:27 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Ben's comments on 4.3, third paragraph from end

Before:

After:

Ulrich,

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Wed, 21 Jan 2015 10:45:41 -0600

> 1. Two answer messages (with same application id) sent by a reporting node while not in an overload condition can have different selected overload abatement algorithms in the OC-Feature-Vector AVP.

SRD> Correct, one set of answer messages could indicate loss and the 
other rate (for instance).  This would happen if the reporting node 
policy prefers rate but there is a mix of reacting node capabilities.  
In this case where not all reacting nodes support the reporting nodes 
preferred algorithm, the reporting node could also decide to send loss 
to all reacting nodes.

> 2. Two answer messages (with same application id) sent by a reporting node while in an (the same) overload condition must have the same selected overload abatement algorithm in the OC-Feature-Vecto…

SRD> I'm a little lost in your description here.  It is possible for the 
reporting node be in an overload state and be sending loss reports to 
one set of reacting nodes and rate to a second set of reacting nodes.  
Whether or not the reporting node does this is entirely up to the 
implementation at the reporting node.

> This ensures that reacting nodes, while not changing the set of advertized algorithms, will not receive a change of the selected algorithm during an overload condition (without the need for the rep…

SRD> The algorithm sent by the reporting node will be decided based on a 
combination of the advertised algorithms and policy at the reporting 
node.  If there is some change in policy at the reporting node that 
changes the selection then the reacting node needs to be prepared to 
handle the change.  I think you are suggesting we say this cannot happen 
during an active overload at the reporting node.  Is this correct?

SRD> As things stand now, with the changes made in -06 and the coming 
-07, the reacting node will need to be able to handle a change in 
algorithm during an active overload condition.  What is the benefit of 
changing this?  If the algorithm changes during an overload condition 
the reacting node can just treat it as an end of one overload condition 
and the start of another.

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 22 Jan 2015 09:37:29 +0000

Steve,
see inline.
Regards
Ulrich

-----Original Message-----
From: ext Steve Donovan [mailto:[email-masked]] 
Sent: Wednesday, January 21, 2015 5:46 PM
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Ben's comments on 4.3, third paragraph from end

Ulrich> Although this is right, it does not hit the nail. I should have said:
1a. Two answer messages (with same application id) sent by a reporting node while in or not in an overload condition can have different selected overload abatement algorithms in the OC-Feature-Vector AVP when the corresponding request messages advertize different sets of supported algorithms.
1b. Two answer messages (with same application id) sent by a reporting node while not in an overload condition can have different selected overload abatement algorithms in the OC-Feature-Vector AVP even when the corresponding request messages advertize the same set of supported algorithms.
As you say , 1a would happen if there is a mix of reacting node capabilities. 1b would happen if the policy is changed in the reporting node.

Ulrich> yes, loss to the reacting nodes that advertize loss only and rate to the reacting nodes that advertize rate and loss. If we do not allow this, then a reporting node cannot select rate (although supported by most reacting nodes) as long as one reacting node only supports loss.

Ulrich> it is up to configuration: the reporting node may be configured to "select rate when loss and rate is advertized and to select loss when only loss is advertized". Alternatively the reporting node may be configured to "select loss when loss and rate is advertized and to select loss when only loss is advertized".

 
Ulrich> yes. 

Ulrich> yes that is possible but adds complexity to the reacting node especially when changing from a stateless to a stateful algorithm. There may also be issues with the mechanism's stability. During an overload condition reporting nodes should not force reacting nodes to change algorithm.
On reflection, reacting nodes that support (and advertize) loss and rate could - when receiving OLR with loss - stopp advertizing rate as long as the overload condition is ongoing in order to prevent change from loss to rate during the overload condition. With this trick, the only way of change is towards loss, and that may be acceptable (as it is a one time change and you cannot change back and forth).

---

From: Steve Donovan <[email-masked]>
Date: Thu, 22 Jan 2015 08:32:24 -0600

Ulrich,

I agree that the reacting node can do as you say and change what it 
advertises after the start of an overload condition.  Do you agree that 
this does not require any changes to the DOIC spec?  If so, then do you 
agree we can close on this issue?

Regards,

Steve

---

From: Maria Cruz Bartolome <[email-masked]>
Date: Thu, 22 Jan 2015 17:12:42 +0000

Ulrich, Steve,

Not sure closing the issue would mean some rephrasing or you have agreed it is not needed.

Anyway, the last sentence in this paragraph, is saying the same as first part:

4.2, 3rd paragraph from the end:

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: jueves, 22 de enero de 2015 15:32
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Ben's comments on 4.3, third paragraph from end

Ulrich,

I agree that the reacting node can do as you say and change what it advertises after the start of an overload condition.  Do you agree that this does not require any changes to the DOIC spec?  If so, then do you agree we can close on this issue?

Regards,

Steve

On 1/22/15 3:37 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
> SRD> I'm a little lost in your description here.  It is possible for 
> SRD> the
> SRD> The algorithm sent by the reporting node will be decided based on 
> SRD> a
> handle the change.  I think you are suggesting we say this cannot 
> happen during an active overload at the reporting node.  Is this correct?
>   
> Ulrich> yes.
>
> the reacting node can just treat it as an end of one overload 
> condition and the start of another.
>
>>     I have removed the last sentence in the paragraph in question.  
>> The before and after for the paragraph is as follows:
>>
>> Before:
>>
>>>>> during overload. I thought we agreed to remove that. (The 
>>>>> normative text is also still there--see later comment.)
>>>>>

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 23 Jan 2015 09:05:45 +0000

Steve,

I agree with Maria Cruz that the text in -06 is wrong as it says 

   The reporting node is not allowed to change the overload abatement algorithm while
   the reporting node is in an overload condition.

Also your previously suggested modification

>>       in an overload condition and sending overload reports.

Does not clearly say that reporting nodes are allowed to change algorithm during an ongoing overload condition.

Also maybe we can add a note to say that during an ongoing overload condition reacting nodes may chose to stop advertizing support of all algorithms except the one selected by the reporting node and loss in order to prevent change of algorithm (other than towards loss) during an ongoing overload condition.  

Ulrich

-----Original Message-----
From: ext Maria Cruz Bartolome [mailto:[email-masked]] 
Sent: Thursday, January 22, 2015 6:13 PM
To: Steve Donovan; Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: [email-masked]
Subject: RE: [Dime] Ben's comments on 4.3, third paragraph from end

Ulrich, Steve,

Best regards
/MCruz

-----Original Message-----
From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: jueves, 22 de enero de 2015 15:32
To: Wiehe, Ulrich (NSN - DE/Munich); ext Ben Campbell
Cc: [email-masked]
Subject: Re: [Dime] Ben's comments on 4.3, third paragraph from end

Ulrich,

Regards,

Steve

---

From: Steve Donovan <[email-masked]>
Date: Fri, 23 Jan 2015 07:35:10 -0600

> Does not clearly say that reporting nodes are allowed to change algorithm during an ongoing overload condition.
SRD> Agreed.  I think the paragraph can be removed entirely as it will 
just cause confusion.  There are no restrictions on a reporting nodes 
ability to change the selected algorithm.
> Also maybe we can add a note to say that during an ongoing overload condition reacting nodes may chose to stop advertizing support of all algorithms except the one selected by the reporting node an…
SRD> How about if we add the following to the end of 5.1.1: "Reacting 
nodes need to be prepared for the reporting node to change selected 
algorithms.  This can happen at any time, including when the reporting 
node has sent an active overload report.  The reacting node can minimize 
the potential changes by modifying the advertised abatement algorithms 
sent to an overloaded reporting node to the currently selected algorithm 
and loss (or just loss if it is the currently selected algorithm).  This 
has the effect of limiting the potential change in abatement algorithm 
from the currently selected algorithm to loss, avoiding changes to more 
complex abatement algorithms that require state to operate properly."

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Fri, 23 Jan 2015 13:38:06 +0000

Fine with me.
Ulrich