Subject: [Dime] DOIC WGLC: Changing Algorithms

From: Ben Campbell <[email-masked]>
Date: Tue, 16 Dec 2014 22:48:40 -0600

Section 4.1.2, (4th paragraph from end ) says that a reporting node cannot change algorithms during an active overload condition. We fail to say anything about when reacting nodes could change their list of supported algorithms. That leaves us with the question about what happens if a reporting node has an active OCS, and gets a new request with an OC-S-F that does not support the active algorithm.

The obvious answer is that reacting nodes shouldn't do that-- but I think there would still be legal scenarios where it could happen anyway. So even if we say that a single reacting node should not change its algorithm list while it has active OCS, we still need to handle the situation for reporting nodes.

---

From: Jouni Korhonen <[email-masked]>
Date: Wed, 17 Dec 2014 09:11:54 +0200

While changing algorithm "on fly" is undesirable both reporting and 
reacting nodes need to be prepared for the situation, specifically if 
the reacting node keeps advertising multiple supported algorithms.

I think we need to flag this better in the text but stress that such 
behaviour is not desired. And in some cases not even possible to do 
cleanly (depending on the algorithm).

- Jouni

12/17/2014 6:48 AM, Ben Campbell kirjoitti:
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime
>

---

From: Steve Donovan <[email-masked]>
Date: Wed, 17 Dec 2014 08:28:13 -0600

The only way for a reacting node to attempt to change the algorithm is 
by removing an algorithm that had been advertised before the overload 
condition started and stopping to advertise it during an overload condition.

   C------------------>S   The reacting node advertises loss and rate
    OC-S-F(loss+rate)
   C<------------------S   The reporting node enters overload using the 
rate algorithm
           OC-S-F(rate)
           OC-OLR(...)
   C------------------>S   The reacting node stops advertising the rate 
algorithm
     OC-S-F(loss)

It is certainly conceivable that this could happen as a result of 
configuration changes at the reacting node.

I don't think, however, that we need to add any behavior changes for the 
reporting node in this case.  It is reasonable to expect a reacting node 
to continue to support an abatement algorithm it was advertising when an 
overload occurrence started for the duration of that active overload 
occurrence.  In fact, it would be detrimental to the reporting node, 
which is in an overload state, to do extra work because a reacting node 
started sending a different set of features in the OC-S-F AVP.

We already say that a reporting node must not change the algorithm 
during an active overload condition.  I propose that we strengthen this 
to include when a new set of features and abatement algorithms are 
advertised by the reporting node.  Those new features and abatement 
algorithms cannot go into effect until the existing active overload 
condition is resolved.  This would look like the following on the wire:

   C------------------>S   The reacting node advertises loss and rate
    OC-S-F(loss+rate)
   C<------------------S   The reporting node enters overload using the 
rate algorithm
           OC-S-F(rate)
           OC-OLR(...)
   C------------------>S   The reacting node stops advertising the rate 
algorithm
     OC-S-F(loss)
   C<------------------S   The reporting node ignores the new set of 
features
           OC-S-F(rate)
           OC-OLR(...)
   C------------------>S
     OC-S-F(loss)
   C<------------------S   The overload condition ends
           OC-S-F(rate)
           OC-OLR(Validity-Duration:0)
   C------------------>S   The reporting node processes the new set of 
features
     OC-S-F(loss)
   C<------------------S
           OC-S-F(loss)

Steve

On 12/17/14, 1:11 AM, Jouni Korhonen wrote:
>> Section 4.1.2, (4th paragraph from end ) says that a reporting node 
>> cannot change algorithms during an active overload condition. We fail 
>> to say anything about when reacting nodes could change their list of 
>> supported algorithms. That leaves us with the question about what 
>> happens if a reporting node has an active OCS, and gets a new request 
>> with an OC-S-F that does not support the active algorithm.
>>
>> The obvious answer is that reacting nodes shouldn't do that-- but I 
>> think there would still be legal scenarios where it could happen 
>> anyway. So even if we say that a single reacting node should not 
>> change its algorithm list while it has active OCS, we still need to 
>> handle the situation for reporting nodes.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 Dec 2014 10:28:45 -0600

I seem to be completely failing at describing the issue.

Imagine this picture:

C1---
        \
          -------A------S
	 /
C2---

Now, assume S is overloaded. Consider two cases:

1) C1 and C2 support DOIC. A either doesn't support it, or does support it but passes DCA unchanged. Is this flow legal? (I assume "yes", since "no" would have some nasty implications about mixed capability environments.)

C1 ------>A------>S
(loss + rate)
C1 <------A<------S
                   (rate)
                   (OLR-rate)
C2------->A------>S
(loss)
C2<------A<-------S
                   (loss)
                   (OLR-loss)

2) Now assume C1 and C2 do not support DOIC, but A does, but A changes config mid way through. According to your proposal, I _think_ it would work like this (see difference in last answer)

C1 ------>A------>S
                 (loss + rate)
C1 <------A<------S
                   (rate)
                   (OLR-rate)
C2------->A------>S
                    (loss)
C2<------A<-------S
                   (_rate_)
                   (OLR-rate)

The problem is, S cannot tell the difference between the two flows. In the first case, there are two separate reacting nodes with different capabilities. In the second case there's a single reacting node with changing capabilities. But from S's perspective, the requests look exactly the same.

(At this point, some one will point out that in the first case, the OC-S-F difference can correspond to different Origin-Host values, and in case 2 they do not. Maybe S can infer the difference from that. To that, I say assume now that C1 and C2 are really agents, and all the traffic is coming from a single client behind them. The issue would be the same, but Origin-Host would never change.)

> On Dec 17, 2014, at 8:28 AM, Steve Donovan <[email-masked]> wrote:
> 
> The only way for a reacting node to attempt to change the algorithm is by removing an algorithm that had been advertised before the overload condition started and stopping to advertise it during an overload condition.
> 
>  C<------------------S   The reporting node enters overload using the rate algorithm
>          OC-S-F(rate)
>          OC-OLR(...)
>  C------------------>S   The reacting node stops advertising the rate algorithm
>    OC-S-F(loss)
> 
> It is certainly conceivable that this could happen as a result of configuration changes at the reacting node.
> 
> I don't think, however, that we need to add any behavior changes for the reporting node in this case.  It is reasonable to expect a reacting node to continue to support an abatement algorithm it was advertising when an overload occurrence started for the duration of that active overload occurrence.  In fact, it would be detrimental to the reporting node, which is in an overload state, to do extra work because a reacting node started sending a different set of features in the OC-S-F AVP.
> 
> We already say that a reporting node must not change the algorithm during an active overload condition.  I propose that we strengthen this to include when a new set of features and abatement algorithms are advertised by the reporting node.  Those new features and abatement algorithms cannot go into effect until the existing active overload condition is resolved.  This would look like the following on the wire:
> 
>  C<------------------S   The reporting node enters overload using the rate algorithm
>          OC-S-F(rate)
>          OC-OLR(...)
>  C------------------>S   The reacting node stops advertising the rate algorithm
>    OC-S-F(loss)
>  C<------------------S   The reporting node ignores the new set of features
>          OC-S-F(rate)
>          OC-OLR(...)
>  C------------------>S
>    OC-S-F(loss)
>  C------------------>S   The reporting node processes the new set of features
>    OC-S-F(loss)
>  C<------------------S
>          OC-S-F(loss)
> 
> Steve
> 
>> While changing algorithm "on fly" is undesirable both reporting and reacting nodes need to be prepared for the situation, specifically if the reacting node keeps advertising multiple supported algorithms.
>> 
>> I think we need to flag this better in the text but stress that such behaviour is not desired. And in some cases not even possible to do cleanly (depending on the algorithm).
>> 
>> - Jouni
>>

---

From: Steve Donovan <[email-masked]>
Date: Wed, 17 Dec 2014 11:26:11 -0600

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.

More inline.

Steve

> 1) C1 and C2 support DOIC. A either doesn't support it, or does support it but passes DCA unchanged. Is this flow legal? (I assume "yes", since "no" would have some nasty implications about mixed c…
SRD> Yes, this is legal and is no different then the case where C1 and 
C2 are directly connected to S.
> 2) Now assume C1 and C2 do not support DOIC, but A does, but A changes config mid way through. According to your proposal, I _think_ it would work like this (see difference in last answer)
SRD> In this case S would need to select loss because the reacting node 
for C2 only supports loss.  It doesn't matter if the reacting node for 
C2 resides in the element called C2 or if it resides in A.  All S needs 
to know is if there is a reacting node for traffic originated by C2.  S 
differentiates the source of the traffic using the Origin-Host AVP in 
the request messages.
> The problem is, S cannot tell the difference between the two flows. In the first case, there are two separate reacting nodes with different capabilities. In the second case there's a single reactin…
SRD> There are two separate reacting nodes in the second case as well.  
They are "virtual" reacting nodes that happen to reside in A.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 Dec 2014 11:41:54 -0600

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 legal and is no different then the case where C1 and C2 are directly connected to S.
>> 
> SRD> In this case S would need to select loss because the reacting node for C2 only supports loss.  It doesn't matter if the reacting node for C2 resides in the element called C2 or if it resides in A.  All S needs to know is if there is a reacting node for traffic originated by C2.  S differentiates the source of the traffic using the Origin-Host AVP in the request messages.

If we expect a separate reacting node "instance" for each request origin-host, we need to say so. But it still doesn't work for the single client example.

> SRD> There are two separate reacting nodes in the second case as well.  They are "virtual" reacting nodes that happen to reside in A.

Where does the draft say or even imply that? It would make sense if we were asking for different abatement for C1 and C2, but we are not.  But in any case, consider the single client example above.

---

From: Steve Donovan <[email-masked]>
Date: Wed, 17 Dec 2014 12:34:49 -0600

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

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.

> If we expect a separate reacting node "instance" for each request origin-host, we need to say so. But it still doesn't work for the single client example.
SRD> We can certainly make it explicit.
> Where does the draft say or even imply that? It would make sense if we were asking for different abatement for C1 and C2, but we are not.  But in any case, consider the single client example above.
SRD> Section 4.1.3, second paragraph - "A Diameter Agent SHOULD take on 
reacting node behavior for Diameter endpoints that do not support the 
DOIC solution."

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 Dec 2014 12:51:44 -0600

> On Dec 17, 2014, at 12:34 PM, Steve Donovan <[email-masked]> wrote:
> 
> SRD> Section 4.1.3, second paragraph - "A Diameter Agent SHOULD take on reacting node behavior for Diameter endpoints that do not support the DOIC solution."
> 

I don't think that, as written, implies a separate virtual reacting node (I assume with potentially distinct capabilities) for each non-supporting client.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 Dec 2014 13:00:07 -0600

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

---

From: Steve Donovan <[email-masked]>
Date: Wed, 17 Dec 2014 15:35:31 -0600

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

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.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 Dec 2014 15:54:14 -0600

> On Dec 17, 2014, at 3:35 PM, Steve Donovan <[email-masked]> wrote:
> 
> 
> 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. 

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

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

---

From: Steve Donovan <[email-masked]>
Date: Wed, 17 Dec 2014 16:23:46 -0600

> 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…
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.  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 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 spe…
SRD> We already have the restriction on the reporting node.
> 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 th…
SRD> Multiple reacting nodes with different capabilities is all the more 
reason to hold things constant during an overload condition.  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.
> 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…
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.

---

From: Ben Campbell <[email-masked]>
Date: Wed, 17 Dec 2014 16:38:56 -0600

> On Dec 17, 2014, at 4:23 PM, Steve Donovan <[email-masked]> wrote:
> 
> 
> 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.

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

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

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 18 Dec 2014 17:46:32 +0000

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

---

From: Ben Campbell <[email-masked]>
Date: Fri, 19 Dec 2014 13:58:16 -0600

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:

---

From: "Wiehe, Ulrich (NSN - DE/Munich)" <[email-masked]>
Date: Tue, 23 Dec 2014 16:57:23 +0000

Ben, Steve,
I do not agree.

Assume the following example:
A reporting node S supports 3 algorithms: Loss, AlgoA, and AlgoB.
For a given reacting node C this results in 4 possible cases of commonly supported algorithms:
Case a) only Loss is commonly supported by S and C
Case b) Loss and AlgoA are the only commonly supported algorithms by S an C,
Case c) Loss and AlgoB are the only commonly supported algorithms by S and C,
Case d) Loss, AlgoA, and AlgoB are the only commonly supported algorithms by S and C.

Now S may be configured to select Loss in case a), AlgoA in case b), AlgoB in case c), and AlgoA in case d).
(Actually a modification of this configuration is regarded a change of algorithm and must not be done while in an overload condition)

When entering an overload condition, S has to create and maintain 3 OCSs, one for Loss, one for AlgoA, and one for AlgoB.

When receiving a request from a reacting node Ca (case a)), S returns the OLR that corresponds to the Loss OCS.
When receiving a request from a reacting node Cb (case b)), S returns the OLR that corresponds to the AlgoA OCS.
When receiving a request from a reacting node Cc (case c)), S returns the OLR that corresponds to the AlgoB OCS.
When receiving a request from a reacting node Cd (case d)), S returns the OLR that corresponds to the AlgoA OCS.

Let's focus on reacting node Cc. It advertizes Loss and AlgoB (and possibly additional algorithms that are not supported by S). Assume this reacting node now also supports AlgoA. Why would the reacting node not be allowed to immediately return the OLR that corresponds to the AlgoA OCS?
Keeping sending of OLRs that correspond to the AlgoB OSC would require the reporting node to keep state. (the actual case is case d) (as can be determined from the received request) while the case when the first request from Cc was received after entering the overload condition was case c) (can only be determined from a stored state).

In summary: the reporting node should be allowed to change algorithm simply because the reacting node advertises other algorithms in addition to one currently in use.

Now let's focus on node Cb. It advertizes Loss and AlgoA. Why would it not be allowed for Cb to stopp advertizing AlgoA? S would immediately return the OLR that corresponds to the Loss OCS. S would not even be required to be aware of the change. S just bases its action on the content of the received request, no need to maintain a node-specific state.

In summary the reporting node is allowed to change the set of advertized algorithms at any time, as long as it is prepared to accept the consequences.

The real requirement for not changing algorithm during overload is for the reporting node: The reporting node MUST NOT change the selected algorithm while the reacting node did not change the set of advertized algorithms.

This requirement can be met without keeping reacting-node-specific state.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[email-masked]] 
Sent: Friday, December 19, 2014 8:58 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: Steve Donovan; [email-masked]
Subject: Re: [Dime] DOIC WGLC: Changing Algorithms

In 4.1.2:

Old:

New:

Added text in 4.1.1: