Subject: Re: [Dime] DOIC WGLC: Changing Algorithms

From: Steve Donovan <[email-masked]>
Date: Wed, 07 Jan 2015 09:56:12 -0600

All,

After further discussion with Ben, the recommendation is to NOT include 
the wording proposed in the attached email.  Instead I propose to add 
the following wording in section 4.1.3 (section 5.1.3 in version -06) 
after the third paragraph:

           Note: When multiple agents are serving as the reacting node 
for a non supporting
           Diameter endpoint, each of those agents will be advertising 
capabilities for
           what looks to the reporting node like a single entity. Care 
should be taken
           to ensure that reporting node behavior is not adversely 
impacted in this scenario.
           For instance, if frequent changes in advertised features is a 
concern then
           care needs to be taken to ensure that all agents advertising 
capabilities for
           a single entity advertise the same DOIC features.

Regards,

Steve

On 12/19/14 1:58 PM, Ben Campbell wrote:
> Steve and I had an offline discussion, and I think we agree that the reporting node can be forced to change algorithms during an active overload condition, if it gets a request that doesn't advertise support for the active algorithm.
>
> We currently have text forbidding the reporting node from changing algorithms during an active overload condition, without making this exception. We assume that we still want to otherwise keep the limitation on algorithm changes during overload. Here's a concrete proposal:
>
> In 4.1.2:
>
> Old:
>
> For an ongoing overload condition, a reporting node MUST NOT change the selected algorithm during the period of time that it is in an overload condition and, as a result, is sending OC-OLR AVPs in answer messages.
>
> New:
>
> For an ongoing overload condition, a reporting node MUST NOT initiate a change to the selected algorithm during the period of time that it is in an overload condition and, as a result, is sending OC-OLR AVPs in answer messages. This rule does not affect the case where the OC-Supported-Features in a new request matching the OLR does not advertise support for the current algorithm, in which case the reporting node would be forced to change algorithms. However, this rule does constrain the reporting node from changing algorithms simply because the reacting node advertises other algorithms in addition to one currently in use.
>
> Added text in 4.1.1:
>
> If a reacting node is using an abatement algorithm to abate traffic due to an active OLR from a reporting node, the reacting node SHOULD continue to advertise support for that algorithm in future requests that match the OLR, until the overload condition is terminated.
>
>
>> On Dec 18, 2014, at 11:46 AM, Wiehe, Ulrich (NSN - DE/Munich) <[email-masked]> wrote:
>>
>> Ben, Steve,
>>
>> Section 4.2.1.2 says:
>>    A reporting node SHOULD maintain OCS entries per supported Diameter
>>    application, per supported (and eventually selected) Abatement
>>    Algorithm and per report-type.
>>
>> For example, an HSS would maintain two OCSs for S6a host-type reports, one for loss and one for rate. When receiving a request that advertises only loss, the returned OLR would be the one according to the loss-OCS; When receiving a request that advertises loss and rate, the HSS has two returned OLR would be the one according to the rate-OCS.
>>
>> I don't see a problem when algorithm is changed at the reacting node.
>>
>> Ulrich
>>
>>
>>
>> -----Original Message-----
>> From: DiME [mailto:[email-masked]] On Behalf Of ext Ben Campbell
>> Sent: Wednesday, December 17, 2014 11:39 PM
>> To: Steve Donovan
>> Cc: [email-masked]
>> Subject: Re: [Dime] DOIC WGLC: Changing Algorithms
>>
>>
>>> On Dec 17, 2014, at 4:23 PM, Steve Donovan <[email-masked]> wrote:
>>>
>>>
>>> On 12/17/14 3:54 PM, Ben Campbell wrote:
>>>>> On Dec 17, 2014, at 3:35 PM, Steve Donovan <[email-masked]> wrote:
>>>>>
>>>>>
>>>>> On 12/17/14 1:00 PM, Ben Campbell wrote:
>>>>>>> On Dec 17, 2014, at 12:34 PM, Steve Donovan <[email-masked]> wrote:
>>>>>>>
>>>>>>>> Okay, new picture:
>>>>>>>>
>>>>>>>>
>>>>>>>>> On Dec 17, 2014, at 11:26 AM, Steve Donovan <[email-masked]>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> Ben,
>>>>>>>>>
>>>>>>>>> The value of the Origin-Host matters greatly here.  In both cases, what S needs to know is if there is a reacting node for traffic coming from C1 and if there is a reacting node for traffic coming from C2.
>>>>>>>>>
>>>>>>>> There is no assumption in the draft right now that we have a correlation between reacting nodes and clients. That might be required for client-targed OLRs, but we don't have those yet.
>>>>>>>>
>>>>>>>> Consider a different picture. In this case, C never supports DOIC. the reacting node role happens either at A1/A2 or at A3, depending on which flow you look at.
>>>>>>>>
>>>>>>>>         A1---
>>>>>>>>        /         \
>>>>>>>> C --             -------A3------S
>>>>>>>>        \         /
>>>>>>>>          A2---
>>>>>>>>
>>>>>>>> Now, assume the same flows, but substitute A1 for C1, A2, for C2, and A3 for A. All requests now have the same origin-host.
>>>>>>>>
>>>>>>>> Before you say this is unrealistic: The issue is the same for any situation where one client can send traffic across multiple agents to the same destination. It doesn't matter if there is one or a million.
>>>>>>>>
>>>>>>> SRD> Yes, this is nasty.  With attribution S can detect the scenario.  I'm not sure what it does once it selects it.  This can be addressed to some degree by adding a deployment recommendation that  all agents taking on reacting node functionality for a single endpoint  select the same algorithm.
>>>>>> I think some sort of attribution is the long-term solution. Another option might be some sort of DCA state identifier, or a combination of the two. (e.g. multiple "virtual" reacting node at the same physical node.) The details will be non-trivial to figure out.
>>>>>>
>>>>>> But to close the loop, I think the _short_ term solution is to say that, while a reporting node should not _initiate_ a change in algorithms during an overload condition, it must still handle the situation where the reacting node forces a change. We could go further to say that reacting node also should not initiate such a change, but we would have to recognize that there are scenarios where that guidance cannot be enforced, and the reporting node still has to handle them.
>>>>>>
>>>>>> We might need to think about what it means from an OCS perspective for a reporting node to send OLRs with different algorithms (or potentially other capability parameters) for the "same" overload event.
>>>>> SRD> I think it is a better solution to stay with what we have now.  The reporting node MUST NOT change the algorithm during an active overload condition.  If a reacting node advertises support for it, the reacting node is saying it will support that algorithm for the duration of any overload condition that happens prior to the reacting node changing the advertised algorithm.  The change in advertised algorithm will take effect after the overload condition goes away.
>>>>>
>>>> I disagree. I don't think we want to allow the reporting node to ever indicate an algorithm that was not advertised in the request. That violates normative language earlier in the section that says the selected algorithm MUST be one of the ones advertised in the request. It can also cause problems for reacting nodes, where they get OLRs for an algorithm they don't understand.
>>> SRD> They clearly do understand the algorithm.  They advertised it before the overload report started.  We can change the normative language to cover this exception.
>> In my first scenario, this is not true. C2 (or A2)  _never_ understood the rate algorithm, and never advertised support for it.
>>
>> The whole point of this exercise was to show that the reporting node cannot, in the general case, distinguish between multiple reacting nodes with different capabilities, and a single reacting node that changes capabilities.
>>
>> By "general case", I mean no assumption that the reacting nodes are peers with the reporting nodes, and no assumption that you can correlate origin-host values (in requests) to reacting-nodes.
>>
>>
>>> I think the principle of minimizing work on an overloaded reporting node is the more important principle here.  If the reacting node changes the advertised set of algorithms during an active overload condition then the overloaded reporting node will be required to send end-of-overload OLRs for the previous algorithm and then send start-of-overload OLRs for the new algorithm.  This seems complex at a time the overloaded node should be focusing on getting out of the overload condition.
>> Sending an OLR that the reacting node does not understand will not help you get out of overload.
>>
>> I don't see how this is any more complex that if you simply have multiple reacting nodes with different capabilities--and I don't see how to avoid supporting that case.
>>
>>>> I think that's considerably more important that restricting the reporting node from changing algorithms (Which, btw, does no harm with the only algorithms that we are seriously contemplating.We speculate that it might cause harm for some future algorithm.)
>>> SRD> We already have the restriction on the reporting node.
>> We already have both restrictions, and they contradict. I believe the _existing_ restriction to not select an algorithm that is not advertised in the request is more important than the _existing_ restriction to not change algorithms during an overload condition.
>>
>>
>>>> Remember, this is not just about a single reacting node changing it's capabilities, it's also about multiple reacting nodes with different capabilities. We can't disallow one without disallowing the other.
>>> SRD> Multiple reacting nodes with different capabilities is all the more reason to hold things constant during an overload condition.
>> I don't follow that. You seem to be pushing towards using the same algorithm for all reacting nodes once an overload condition starts. Is that your intent?  (Given the possibility that some future reacting node will only support "loss", that "same algorithm" would pretty much always need to be loss.)
>>
>>> I'm not proposing disallowing reacting nodes from changing the set of capabilities, I'm proposing that these changes don't take effect while there is an active overload condition.
>> The problem exists even if no reacting node ever changes its capabilities.
>>
>>>>
>>>>> SRD> I don't think we need to update the OCS in this document to handle multiple algorithms.  This can be done in the extension drafts.  We might want to make it clear, as it appears it isn't already, that a reacting node might need to support multiple algorithms at the same time.
>>>> Do you mean reacting or reporting node in the last sentence? Assuming you mean it as written, the problem is not that a reacting node may need to support multiple algorithms at the same time. It's that it may get OLRs that it cannot act upon because it doesn't support the algorithm.
>>> SRD> I meant reporting nodes.
>>>> If, otoh, you meant reporting node, I don't understand how a reporting node can have multiple algorithms for the same overload event, without reflecting that possibility in the OCS.
>>> SRD> Yes, it will need to be reflected in the OCS.  We don't have multiple algorithms now so it isn't needed now.  I'm saying we might want to say it might me needed in the future.
>> I'd rather not make each new algorithm redefine the basic structure of OCS.
>>
>> But, if you recall, my point was to say we need to _think_ about how this impacts OCS, not that we necessarily need to change anything. Are you opposed to thinking about it? (And no, I don't think this short exchange quite counts as that.)
>>
>>>>
>>>>
>> _______________________________________________
>> 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: Ben Campbell <[email-masked]>
Date: Wed, 7 Jan 2015 10:13:05 -0600

I am almost okay with that. But on reflection, I think the issue is broader than described in the first sentence.

For example (SE == supporting endpoint, NSE == non-supporting endpoint, etc.)

SE ----
            \
              ----NSA ---- RepNode
SE ---- /

... and ...

NSE ----
              \
                ----SA ---- RepNode
NSE ---- /

These scenarios look exactly the same from the reporting node's perspective. That is, the Reporting Node cannot tell if it has multiple supporting endpoints with different features, or one supporting agent that is arbitrarily changing its advertised features.  You can also run into the issue if all nodes support DOIC, if agents modify OC-S-F.

So now (and admitting to opinion flapping), I wonder if the guidance should be that the Reporting Node cannot depend on consistent OC capabilities between requests, and must be prepared in general to deal with frequent changes in advertised features.

> On Jan 7, 2015, at 9:56 AM, Steve Donovan <[email-masked]> wrote:
> 
> All,
> 
> After further discussion with Ben, the recommendation is to NOT include the wording proposed in the attached email.  Instead I propose to add the following wording in section 4.1.3 (section 5.1.3 in version -06) after the third paragraph:
> 
>          Note: When multiple agents are serving as the reacting node for a non supporting
>          Diameter endpoint, each of those agents will be advertising capabilities for
>          what looks to the reporting node like a single entity. Care should be taken
>          to ensure that reporting node behavior is not adversely impacted in this scenario.
>          For instance, if frequent changes in advertised features is a concern then
>          care needs to be taken to ensure that all agents advertising capabilities for

---

From: Steve Donovan <[email-masked]>
Date: Wed, 07 Jan 2015 10:51:20 -0600

Yes, reporting nodes cannot depend on consistent capabilities between 
requests.  I don't find were we say that directly (in a very quick look) 
but it is implied by the fact that OC-S-F MUST be included in all 
requests and, as such, capabilities announcement does not span transactions.

Maybe, in addition to the paragraph below that give guidance for agent 
based cases, we should add the following in Section 4.1.2 (5.1.2 in 
DOIC-06) after paragraph 2:

   "Note:  Capability announcement is done per transaction.  The 
reporting node cannot assume that the capabilities announced by a 
reacting node will be the same between transactions."

Regards,

Steve

---

From: Ben Campbell <[email-masked]>
Date: Wed, 7 Jan 2015 12:47:11 -0600

The note in 4.1.2 would be reasonable.

Here's a proposed alternative for your previous suggested paragraph:

Note: This specification assumes that changes in DOIC node capabilities are relatively rare events that occur as a result of administrative action. Reacting nodes ought to minimize changes that force the reporting node to change the features being used, especially during active overload conditions. But even if reacting nodes avoid such changes, reporting nodes still have to be prepared for them to occur. For example, differing capabilities between multiple reacting nodes may still force a reporting node to select different features on a per-transaction basis.

If we accept this proposal, it probably should go in 4.1.1, since it’s no longer really about agents.

> On Jan 7, 2015, at 10:51 AM, Steve Donovan <[email-masked]> wrote:
> 
> Yes, reporting nodes cannot depend on consistent capabilities between requests.  I don't find were we say that directly (in a very quick look) but it is implied by the fact that OC-S-F MUST be included in all requests and, as such, capabilities announcement does not span transactions.
> 
> Maybe, in addition to the paragraph below that give guidance for agent based cases, we should add the following in Section 4.1.2 (5.1.2 in DOIC-06) after paragraph 2:
> 
>  "Note:  Capability announcement is done per transaction.  The reporting node cannot assume that the capabilities announced by a reacting node will be the same between transactions."
> 
> Regards,
> 
> Steve
>

---

From: Steve Donovan <[email-masked]>
Date: Wed, 07 Jan 2015 16:36:19 -0600

I'm good with this.

Steve

On 1/7/15 12:47 PM, Ben Campbell wrote:
>     Note: This specification assumes that changes in DOIC node
>     capabilities are relatively rare events that occur as a result of
>     administrative action. Reacting nodes ought to minimize changes
>     that force the reporting node to change the features being used,
>     especially during active overload conditions. But even if reacting
>     nodes avoid such changes, reporting nodes still have to be
>     prepared for them to occur. For example, differing capabilities
>     between multiple reacting nodes may still force a reporting node
>     to select different features on a per-transaction basis.
>
>
>> On Jan 7, 2015, at 10:51 AM, Steve Donovan <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> requests.  I don't find were we say that directly (in a very quick 
>> look) but it is implied by the fact that OC-S-F MUST be included in 
>> all requests and, as such, capabilities announcement does not span 
>> transactions.
>>
>> Maybe, in addition to the paragraph below that give guidance for 
>> agent based cases, we should add the following in Section 4.1.2 
>> (5.1.2 in DOIC-06) after paragraph 2:
>>
>>> I am almost okay with that. But on reflection, I think the issue is 
>>> broader than described in the first sentence.
>>>
>>> These scenarios look exactly the same from the reporting node's 
>>> perspective. That is, the Reporting Node cannot tell if it has 
>>> multiple supporting endpoints with different features, or one 
>>> supporting agent that is arbitrarily changing its advertised 
>>> features.  You can also run into the issue if all nodes support 
>>> DOIC, if agents modify OC-S-F.
>>>
>>> So now (and admitting to opinion flapping), I wonder if the guidance 
>>> should be that the Reporting Node cannot depend on consistent OC 
>>> capabilities between requests, and must be prepared in general to 
>>> deal with frequent changes in advertised features.
>>>
>>>
>>>> On Jan 7, 2015, at 9:56 AM, Steve Donovan <[email-masked] 
>>>> <mailto:[email-masked]>> wrote:
>>>>
>>>> All,
>>>>
>>>> After further discussion with Ben, the recommendation is to NOT 
>>>> include the wording proposed in the attached email.  Instead I 
>>>> propose to add the following wording in section 4.1.3 (section 
>>>> 5.1.3 in version -06) after the third paragraph:
>>>>
>>>>> Steve and I had an offline discussion, and I think we agree that 
>>>>> the reporting node can be forced to change algorithms during an 
>>>>> active overload condition, if it gets a request that doesn't 
>>>>> advertise support for the active algorithm.
>>>>>
>>>>> We currently have text forbidding the reporting node from changing 
>>>>> algorithms during an active overload condition, without making 
>>>>> this exception. We assume that we still want to otherwise keep the 
>>>>> limitation on algorithm changes during overload. Here's a concrete 
>>>>> proposal:
>>>>>
>>>>> In 4.1.2:
>>>>>
>>>>> Old:
>>>>>
>>>>> For an ongoing overload condition, a reporting node MUST NOT 
>>>>> change the selected algorithm during the period of time that it is 
>>>>> in an overload condition and, as a result, is sending OC-OLR AVPs 
>>>>> in answer messages.
>>>>>
>>>>> New:
>>>>>
>>>>> For an ongoing overload condition, a reporting node MUST NOT 
>>>>> initiate a change to the selected algorithm during the period of 
>>>>> time that it is in an overload condition and, as a result, is 
>>>>> sending OC-OLR AVPs in answer messages. This rule does not affect 
>>>>> the case where the OC-Supported-Features in a new request matching 
>>>>> the OLR does not advertise support for the current algorithm, in 
>>>>> which case the reporting node would be forced to change 
>>>>> algorithms. However, this rule does constrain the reporting node 
>>>>> from changing algorithms simply because the reacting node 
>>>>> advertises other algorithms in addition to one currently in use.
>>>>>
>>>>> Added text in 4.1.1:
>>>>>
>>>>> If a reacting node is using an abatement algorithm to abate 
>>>>> traffic due to an active OLR from a reporting node, the reacting 
>>>>> node SHOULD continue to advertise support for that algorithm in 
>>>>> future requests that match the OLR, until the overload condition 
>>>>> is terminated.
>>>>>
>>>>>
>>>>>> On Dec 18, 2014, at 11:46 AM, Wiehe, Ulrich (NSN - DE/Munich) 
>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>> Ben, Steve,
>>>>>>
>>>>>> Section 4.2.1.2 says:
>>>>>> For example, an HSS would maintain two OCSs for S6a host-type 
>>>>>> reports, one for loss and one for rate. When receiving a request 
>>>>>> that advertises only loss, the returned OLR would be the one 
>>>>>> according to the loss-OCS; When receiving a request that 
>>>>>> advertises loss and rate, the HSS has two returned OLR would be 
>>>>>> the one according to the rate-OCS.
>>>>>>
>>>>>> Cc: [email-masked] <mailto:[email-masked]>
>>>>>>> On Dec 17, 2014, at 4:23 PM, Steve Donovan 
>>>>>>> <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>>> On Dec 17, 2014, at 3:35 PM, Steve Donovan 
>>>>>>>>> <[email-masked] <mailto:[email-masked]>> 
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>> On Dec 17, 2014, at 12:34 PM, Steve Donovan 
>>>>>>>>>>> <[email-masked] <mailto:[email-masked]>> 
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> Okay, new picture:
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>> On Dec 17, 2014, at 11:26 AM, Steve Donovan 
>>>>>>>>>>>>> <[email-masked] <mailto:[email-masked]>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Ben,
>>>>>>>>>>>>>
>>>>>>>>>>>>> The value of the Origin-Host matters greatly here.  In 
>>>>>>>>>>>>> both cases, what S needs to know is if there is a reacting 
>>>>>>>>>>>>> node for traffic coming from C1 and if there is a reacting 
>>>>>>>>>>>>> node for traffic coming from C2.
>>>>>>>>>>>>>
>>>>>>>>>>>> There is no assumption in the draft right now that we have 
>>>>>>>>>>>> a correlation between reacting nodes and clients. That 
>>>>>>>>>>>> might be required for client-targed OLRs, but we don't have 
>>>>>>>>>>>> those yet.
>>>>>>>>>>>>
>>>>>>>>>>>> Consider a different picture. In this case, C never 
>>>>>>>>>>>> supports DOIC. the reacting node role happens either at 
>>>>>>>>>>>> A1/A2 or at A3, depending on which flow you look at.
>>>>>>>>>>>>
>>>>>>>>>>>>        A1---
>>>>>>>>>>>>       /         \
>>>>>>>>>>>> C --             -------A3------S
>>>>>>>>>>>>       \         /
>>>>>>>>>>>>         A2---
>>>>>>>>>>>>
>>>>>>>>>>>> Now, assume the same flows, but substitute A1 for C1, A2, 
>>>>>>>>>>>> for C2, and A3 for A. All requests now have the same 
>>>>>>>>>>>> origin-host.
>>>>>>>>>>>>
>>>>>>>>>>>> Before you say this is unrealistic: The issue is the same 
>>>>>>>>>>>> for any situation where one client can send traffic across 
>>>>>>>>>>>> multiple agents to the same destination. It doesn't matter 
>>>>>>>>>>>> if there is one or a million.
>>>>>>>>>>>>
>>>>>>>>>>> SRD> Yes, this is nasty.  With attribution S can detect the 
>>>>>>>>>>> scenario.  I'm not sure what it does once it selects it. 
>>>>>>>>>>>  This can be addressed to some degree by adding a deployment 
>>>>>>>>>>> recommendation that  all agents taking on reacting node 
>>>>>>>>>>> functionality for a single endpoint  select the same algorithm.
>>>>>>>>>> I think some sort of attribution is the long-term solution. 
>>>>>>>>>> Another option might be some sort of DCA state identifier, or 
>>>>>>>>>> a combination of the two. (e.g. multiple "virtual" reacting 
>>>>>>>>>> node at the same physical node.) The details will be 
>>>>>>>>>> non-trivial to figure out.
>>>>>>>>>>
>>>>>>>>>> But to close the loop, I think the _short_ term solution is 
>>>>>>>>>> to say that, while a reporting node should not _initiate_ a 
>>>>>>>>>> change in algorithms during an overload condition, it must 
>>>>>>>>>> still handle the situation where the reacting node forces a 
>>>>>>>>>> change. We could go further to say that reacting node also 
>>>>>>>>>> should not initiate such a change, but we would have to 
>>>>>>>>>> recognize that there are scenarios where that guidance cannot 
>>>>>>>>>> be enforced, and the reporting node still has to handle them.
>>>>>>>>>>
>>>>>>>>>> We might need to think about what it means from an OCS 
>>>>>>>>>> perspective for a reporting node to send OLRs with different 
>>>>>>>>>> algorithms (or potentially other capability parameters) for 
>>>>>>>>>> the "same" overload event.
>>>>>>>>> SRD> I think it is a better solution to stay with what we have 
>>>>>>>>> now.  The reporting node MUST NOT change the algorithm during 
>>>>>>>>> an active overload condition.  If a reacting node advertises 
>>>>>>>>> support for it, the reacting node is saying it will support 
>>>>>>>>> that algorithm for the duration of any overload condition 
>>>>>>>>> that happens prior to the reacting node changing the 
>>>>>>>>> advertised algorithm.  The change in advertised algorithm will 
>>>>>>>>> take effect after the overload condition goes away.
>>>>>>>>>
>>>>>>>> I disagree. I don't think we want to allow the reporting node 
>>>>>>>> to ever indicate an algorithm that was not advertised in the 
>>>>>>>> request. That violates normative language earlier in the 
>>>>>>>> section that says the selected algorithm MUST be one of the 
>>>>>>>> ones advertised in the request. It can also cause problems for 
>>>>>>>> reacting nodes, where they get OLRs for an algorithm they don't 
>>>>>>>> understand.
>>>>>>> SRD> They clearly do understand the algorithm.  They advertised 
>>>>>>> it before the overload report started.  We can change the 
>>>>>>> normative language to cover this exception.
>>>>>> In my first scenario, this is not true. C2 (or A2)  _never_ 
>>>>>> understood the rate algorithm, and never advertised support for it.
>>>>>>
>>>>>> The whole point of this exercise was to show that the reporting 
>>>>>> node cannot, in the general case, distinguish between multiple 
>>>>>> reacting nodes with different capabilities, and a single reacting 
>>>>>> node that changes capabilities.
>>>>>>
>>>>>> By "general case", I mean no assumption that the reacting nodes 
>>>>>> are peers with the reporting nodes, and no assumption that you 
>>>>>> can correlate origin-host values (in requests) to reacting-nodes.
>>>>>>
>>>>>>
>>>>>>> I think the principle of minimizing work on an overloaded 
>>>>>>> reporting node is the more important principle here.  If the 
>>>>>>> reacting node changes the advertised set of algorithms during an 
>>>>>>> active overload condition then the overloaded reporting node 
>>>>>>> will be required to send end-of-overload OLRs for the previous 
>>>>>>> algorithm and then send start-of-overload OLRs for the new 
>>>>>>> algorithm.  This seems complex at a time the overloaded node 
>>>>>>> should be focusing on getting out of the overload condition.
>>>>>> I don't see how this is any more complex that if you simply have 
>>>>>> multiple reacting nodes with different capabilities--and I don't 
>>>>>> see how to avoid supporting that case.
>>>>>>
>>>>>>>> I think that's considerably more important that restricting the 
>>>>>>>> reporting node from changing algorithms (Which, btw, does no 
>>>>>>>> harm with the only algorithms that we are seriously 
>>>>>>>> contemplating.We speculate that it might cause harm for some 
>>>>>>>> future algorithm.)
>>>>>> We already have both restrictions, and they contradict. I believe 
>>>>>> the _existing_ restriction to not select an algorithm that is not 
>>>>>> advertised in the request is more important than the _existing_ 
>>>>>> restriction to not change algorithms during an overload condition.
>>>>>>
>>>>>>
>>>>>>>> Remember, this is not just about a single reacting node 
>>>>>>>> changing it's capabilities, it's also about multiple reacting 
>>>>>>>> nodes with different capabilities. We can't disallow one 
>>>>>>>> without disallowing the other.
>>>>>>> SRD> Multiple reacting nodes with different capabilities is all 
>>>>>>> the more reason to hold things constant during an overload 
>>>>>>> condition.
>>>>>> I don't follow that. You seem to be pushing towards using the 
>>>>>> same algorithm for all reacting nodes once an overload condition 
>>>>>> starts. Is that your intent?  (Given the possibility that some 
>>>>>> future reacting node will only support "loss", that "same 
>>>>>> algorithm" would pretty much always need to be loss.)
>>>>>>
>>>>>>> I'm not proposing disallowing reacting nodes from changing the 
>>>>>>> set of capabilities, I'm proposing that these changes don't take 
>>>>>>> effect while there is an active overload condition.
>>>>>>>>> SRD> I don't think we need to update the OCS in this document 
>>>>>>>>> to handle multiple algorithms.  This can be done in the 
>>>>>>>>> extension drafts.  We might want to make it clear, as it 
>>>>>>>>> appears it isn't already, that a reacting node might need to 
>>>>>>>>> support multiple algorithms at the same time.
>>>>>>>> Do you mean reacting or reporting node in the last sentence? 
>>>>>>>> Assuming you mean it as written, the problem is not that a 
>>>>>>>> reacting node may need to support multiple algorithms at the 
>>>>>>>> same time. It's that it may get OLRs that it cannot act upon 
>>>>>>>> because it doesn't support the algorithm.
>>>>>>>> If, otoh, you meant reporting node, I don't understand how a 
>>>>>>>> reporting node can have multiple algorithms for the same 
>>>>>>>> overload event, without reflecting that possibility in the OCS.
>>>>>>> SRD> Yes, it will need to be reflected in the OCS.  We don't 
>>>>>>> have multiple algorithms now so it isn't needed now.  I'm saying 
>>>>>>> we might want to say it might me needed in the future.
>>>>>> But, if you recall, my point was to say we need to _think_ about 
>>>>>> how this impacts OCS, not that we necessarily need to change 
>>>>>> anything. Are you opposed to thinking about it? (And no, I don't 
>>>>>> think this short exchange quite counts as that.)
>>>>>>
>>>>>>>>
>>>>>> [email-masked] <mailto:[email-masked]>