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

[Steve Donovan <[e-mail]>]

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.

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

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

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.

Steve

On 2/18/14 7:41 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
>
> Steve,
>
>  
>
> first of all I would like to better understand the usecase especially
> on the reporting side.
>
> Which node would act as a reporting node generating new realm-type
> reports?
>
> How would this node detect that the complete realm is in overload (and
> what does that mean? All servers in the realm, also clients? Agents? )?
>
> Would this node be (logically) a single node? If not, how to
> synchronize different new-realm-type reporting nodes so that they
> don't report different things to the same reacting node?
>
>  
>
> Ulrich
>
>  
>
> *From:*DiME [mailto:[e-mail]] *On Behalf Of *ext Steve
> Donovan
> *Sent:* Tuesday, February 18, 2014 1:48 PM
> *To:* [e-mail]
> *Subject:* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>  
>
> It shouldn't be much work to add realm overload to the draft.  We
> would need to do the following (at a minimum):
>
> - Change that name of the current realm report to something like
> "realm-routed".
> - Create a new report type of name realm that applies to all traffic
> routed to the realm.
> - Add a few words in the reporting node section about generation of
> realm reports.
> - Define the interaction between realm, realm-routed and host report
> types.  This is probably the most difficult part that is likely to
> require some discussion.
>
> Other then the section on interactions between report types, I don't
> think this impacts the existing text so it should fold in pretty cleanly.
>
> I'd be happy to take the first shot at this to be included in the -02
> version of the draft if there is consensus to add it.
>
> Steve
>
> On 2/18/14 4:11 AM, Maria Cruz Bartolome wrote:
>
>     Hello all,
>
>      
>
>     Overload of the realm is one of the use cases that is required by
>     3GPP applications.
>
>     And I think this should be part of the basic mechanism, or?
>
>      
>
>     Best regards
>
>     /MCruz
>
>      
>
>     *From:*DiME [mailto:[e-mail]] *On Behalf Of *TROTTIN,
>     JEAN-JACQUES (JEAN-JACQUES)
>     *Sent:* lunes, 17 de febrero de 2014 18:53
>     *To:* [e-mail] <mailto:[e-mail]>
>     *Subject:* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>      
>
>     Hi
>
>      
>
>     I share the view to analyze the overload of the realm as a whole
>     in a separate extension  and see if this lead to another report type.
>
>      
>
>     Best regards
>
>      
>
>     JJacques
>
>       
>
>      
>
>     *De :*DiME [mailto:[e-mail]] *De la part de* Steve
>     Donovan
>     *Envoyé :* lundi 17 février 2014 17:13
>     *À :* Ben Campbell
>     *Cc :* [e-mail] <mailto:[e-mail]> list
>     *Objet :* Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP
>
>      
>
>     I do think it would be a new report type, as it would require
>     different behavior from reacting nodes.
>
>     I'm ok with this being in a separate extension if the group thinks
>     this is the correct approach.  We are creating a good number of
>     relatively small extensions.  It might lead to the need to pull
>     them all together in a future version of the DOIC draft/RFC.
>
>     Steve
>
>     On 2/14/14 4:21 PM, Ben Campbell wrote:
>
>         (Apologies for coming late to this thread)
>
>          
>
>         On Feb 13, 2014, at 6:35 AM, Steve Donovan <[e-mail]> <mailto:[e-mail]> wrote:
>
>          
>
>             Ok, Ok, no reason to gang up on me. :-)
>
>             What we have here is an overload report to reduce realm routed requests.  I think we should be explicit in the draft to define it as such.
>
>              
>
>          
>
>         At the risk of joining the anti-Steve gang, I feel the need to belatedly mention that my personal intent way back when we talked about the mixed-state problem was that realm reports applied to realm-routed requests. 
>
>          
>
>             I am still concerned that we do not have a way to indicate overload of the realm as a whole.  I'll enter a new trouble ticket to capture this issue.
>
>              
>
>          
>
>         I do not object to adding that ability. Would it be a new OLR type? If so, would it need to go in the base draft or could it be an extension?
>
>          
>
>             Steve
>
>          
>
>          
>
>      
>
>
>
>
>     _______________________________________________
>
>     DiME mailing list
>
>     [e-mail] <mailto:[e-mail]>
>
>     https://www.ietf.org/mailman/listinfo/dime
>
>  
>