Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

["Wiehe, Ulrich (NSN - DE/Munich)" <[e-mail]>]

Ben, Steve, all

Let's conclude on #34.
The particular question under discussion here actually belongs to #55

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:[e-mail]] 
Sent: Friday, February 21, 2014 12:16 AM
To: Steve Donovan
Cc: Wiehe, Ulrich (NSN - DE/Munich); [e-mail]
Subject: Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP


On Feb 18, 2014, at 8:54 AM, Steve Donovan <[e-mail]> wrote:

> Ulrich,
> 
> All good questions.
> 
> I mapped out the use case in a previous email with discussing the realm-routed overload report type.  
> 
> Maria Cruz also indicated that this is a 3GPP DOC requirement.  I'm hoping someone involved in the discussions that lead to that requirement can speak up on the use case driving the need for realm reports.
> 
> The means of detection is out of scope for the DOIC draft, just as it is for host and realm-routed report types.  We should, however, include wording to explain how it might be done.  
> 
> A few bullet points outlining a proposed solution.  I can put together a couple of slides explaining this if it would be helpful.
> 
> - The method of detection can be based on the collected status of Diameter nodes in the realm.  It can also be based on the status of the underlying network.  For instance, if there is a network outage that reduces the effective throughput of the signaling network, the best method for handling this might be to signal a realm overload report.
> 
> - The network element detecting the realm status is out of scope for the DOIC document.
> 
> - The Diameter node that reports realm overload can be any Diameter node and is up to the service provider to define.  Assuming we are using Diameter answer messages to transport the realm reports, it would need to be either all agents or all servers.  This is to guarantee that all reacting nodes get the report.

I think "any Diameter node" is too broad. It has to be node that is, at least sometimes, in the path for requests for that particular realm+application.  (Although I note that explicit realm and application AVPs in an OLR would fix that ;-)  )

> 
> - The method that the reporting node is told that the realm is overloaded, triggering the realm overload report, is out of scope for this document.
> 

Agreed, although one possible way to do it would be for the reporting node to be an agent that infers general realm overload based on upstream overload information.

> - Reacting nodes should listen to only one realm overload reporting node.  It is up to the implementation of the realm overload detection element to make sure that all reporting nodes have the same state.

I think this should be restated that realm reports should only be _sent_ by reporting nodes that have full knowledge of and authority for the realm's overload state. But there's no requirement that there be only one, just that if there are more than one they don't contradict each other.

> 
> One way to model this is for an external element being responsible for detecting realm overload and signaling the realm overload reporting nodes of the status using an out of bands mechanism.  All realm overload reporting nodes would be responsible for sending realm overload reports.  Reacting nodes would only listen to one of the reporting nodes.
> 
> There are also security considerations similar to host reports, except that an attack using realm overload reports has a much bigger impact than an attack using host reports.

Yep. IIRC, We already have language in the security considerations that reacting nodes need to properly authorize sources of OLRs. That applies here as well.

(Maybe it's time to propose an "all-realms" report type :-) )