Subject: [Dime] DOIC issue #58 Proposal

From: Steve Donovan <[email-masked]>
Date: Thu, 31 Jul 2014 14:53:06 -0500

All,

Issue #58 deals with the fact that there can be multiple senders of 
realm overload report for the same realm.

Ulrich proposes one aspect of what is required in the issue description:

"In deployments where more than one node is configured to take the role 
of a reporting node for realm-routed-request reports, reacting nodes may 
receive in different answer messages different realm-routed-request type 
OLRs inserted by the different reporting nodes. Although it is expected 
that the different reporting nodes report more or less the same content, 
it cannot be expected that reports are 100% synchronized. Especially 
sequence numbers may differ. To allow reacting nodes correctly detect 
outdates/replays/freshness of OLRs in this scenario, it is proposed that 
realm-routed-request type OLRs are extended to contain the Diameter 
Identity of the reporting node that inserted the realm-routed-request 
type OLR. (e.g. as already proposed in 
draft-donovan-dime-agent-overload-01 
<http://tools.ietf.org/html/draft-donovan-dime-agent-overload-01>). 
Reporting nodes that insert realm-routed-request type OLRs to answer 
messages MUST also insert their Diameter Identity. Reacting nodes MUST 
take the Diameter Identity received within the OLR into account in order 
to detect outdates/replays/freshness. "

I agree with Ulrich that realm reports must include the identity of the 
DOIC node that sends the report.  This would be an optional AVP only 
required for realm reports.  It would not be required for host reports 
as the identity of the sender of the host report is implicitly defined 
by the origin-host in the answer message.

I also agree that the Diameter Identity of the reporting node be used to 
determine if a received report is ignored or used to update existing 
state.  To this end I propose that we add wording that for the duration 
of a realm report, the reacting node only listens for updates to the 
realm report from from the DOIC node that sent the realm report that 
resulted in the realm OCS being stored.

The effect should be that the reacting node will accept a realm report 
from anyone when there is no active OLR for the realm but it will only 
listen to one reporting node when it has an active report.

Steve

---

From: Ben Campbell <[email-masked]>
Date: Thu, 31 Jul 2014 15:38:55 -0500

I don't think this problem is limited to realm reports.

We already know "agent" reports will have a similar issue. But It can happen for host reports in at least a few situations:

-- Agents that send host reports on behalf of non-supporting servers, when more than one such agent exists for a given server.

-- Agents that modify host reports based on some local policy (e.g. the mixed capabilities use case.)

-- Diameter nodes made up as an aggregate of multiple "boxes". (e.g. a blade-based system, a cluster behind a server front end), where they may share a single diameter identity for some purposes.

Beyond that, I think if we ever come up with an end-to-end security solution that is useable for DOIC, it is also likely to require the originating identity to be inserted into OLRs.

Therefore, I think we should generalize this to say the following:  

-- All OLRs should contain the diameter identity of the originator of the report.

-- If a reacting node has an active OLR for a given entity, it only pays attention further reports  for that entity. with the same originating identity. In this context, "entity" means the "thing that is overloaded", i.e. the realm for realm reports, and the host for host reports.

It's worth considering whether an agent that modifies an OLR needs to change the originating identity to itself. Also whether there is any value putting this in OC-S-F.

On Jul 31, 2014, at 2:53 PM, Steve Donovan <[email-masked]> wrote:

> All,
> 
> Issue #58 deals with the fact that there can be multiple senders of realm overload report for the same realm.  
> 
> "In deployments where more than one node is configured to take the role of a reporting node for realm-routed-request reports, reacting nodes may receive in different answer messages different realm-routed-request type OLRs inserted by the different reporting nodes. Although it is expected that the different reporting nodes report more or less the same content, it cannot be expected that reports are 100% synchronized. Especially sequence numbers may differ. To allow reacting nodes correctly detect outdates/replays/freshness of OLRs in this scenario, it is proposed that realm-routed-request type OLRs are extended to contain the Diameter Identity of the reporting node that inserted the realm-routed-request type OLR. (e.g. as already proposed in draft-donovan-dime-agent-overload-01). Reporting nodes that insert realm-routed-request type OLRs to answer messages MUST also insert their Diameter Identity. Reacting nodes MUST take the Diameter Identity received within the OLR into account in order to detect outdates/replays/freshness. "
> 
> I agree with Ulrich that realm reports must include the identity of the DOIC node that sends the report.  This would be an optional AVP only required for realm reports.  It would not be required for host reports as the identity of the sender of the host report is implicitly defined by the origin-host in the answer message.
> 
> I also agree that the Diameter Identity of the reporting node be used to determine if a received report is ignored or used to update existing state.  To this end I propose that we add wording that for the duration of a realm report, the reacting node only listens for updates to the realm report from from the DOIC node that sent the realm report that resulted in the realm OCS being stored.
> 
> The effect should be that the reacting node will accept a realm report from anyone when there is no active OLR for the realm but it will only listen to one reporting node when it has an active report.
> 
> Steve
> 
> 
> 
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "Nirav Salot (nsalot)" <[email-masked]>
Date: Fri, 1 Aug 2014 05:40:20 +0000

Steve,

For this issue, I don't agree to include identity of the DOIC node that sends the report, into the realm reports.

In my view, the issue mentioned below - of two agents not 100% synchronize w.r.t the realm-report - is the related to "how agents synchronized between themselves" and since that is not standardized we should not be developing protocol solution for the case which occurs due to this out-of-standards solution.

Besides, I don't see any issue due to slight miss-synchronization of the realm-reports between two agents since they should still represent the realm load more or less accurately.

Also if the agents are not synchronized and if they are playing the role of DOIC reacting node then they will apply abatement algorithm based on different values (for the same realm). So it does not matter if the client does the same.

Finally, I don't see any value-add of using the "identity of the node that sends the realm-report" to discard the other report related to the same realm. In other words, this same logic can be achieved using sequence-numbers as well, i.e. when the overload-report of an realm is active, the client is going to ignore all the reports of the same realm which has lower sequence number value. So in essence, when two agents are sending realm-reports, one of the reports is automatically ignored by the client if their sequence numbers differ. So the outcome without including the "identity if the node that sends realm report" is same as
>The effect should be that the reacting node will accept a realm report from anyone when there is no active OLR for the realm but it will only listen to one reporting node when it has an active repor…

Regards,
Nirav.

From: DiME [mailto:[email-masked]] On Behalf Of Steve Donovan
Sent: Friday, August 01, 2014 1:23 AM
To: [email-masked]
Subject: [Dime] DOIC issue #58 Proposal

All,

"In deployments where more than one node is configured to take the role of a reporting node for realm-routed-request reports, reacting nodes may receive in different answer messages different realm-routed-request type OLRs inserted by the different reporting nodes. Although it is expected that the different reporting nodes report more or less the same content, it cannot be expected that reports are 100% synchronized. Especially sequence numbers may differ. To allow reacting nodes correctly detect outdates/replays/freshness of OLRs in this scenario, it is proposed that realm-routed-request type OLRs are extended to contain the Diameter Identity of the reporting node that inserted the realm-routed-request type OLR. (e.g. as already proposed in draft-donovan-dime-agent-overload-01<http://tools.ietf.org/html/draft-donovan-dime-agent-overload-01>). Reporting nodes that insert realm-routed-request type OLRs to answer messages MUST also insert their Diameter Identity. Reacting nodes MUST take the Diameter Identity received within the OLR into account in order to detect outdates/replays/freshness. "

Steve