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

["TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[e-mail]>]

Hi all


1)      I come back on this Steve's comment : "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".
This joins one of  my remarks about the overlapping between different reports in a previous mail and drives to the use cases regarding realm overload:


-          If realm overload is due to server overload, I would think that  our current  mechanism dealing with host report and realm (alias realm-routed) report will address / solve server overload  and in consequence indirectly  address / solve  this overload realm  case

-          if realm overload is due to the overload of Diameter agents, we have discussion and a Steve's  proposal   about  Agent overload. I would also think that by addressing / solving the DA overload, it would also address and solve this overload realm  case.

-          About an underlying  network congestion (eg due to network outage), here REQ 13 mentions that "The solution MUST NOT interfere with the congestion control mechanisms of underlying transport protocols". So here I am also questioning if  we may have  duplication or overlapping, and what to do .

-          Have we other realm overload use cases?

So my current thinking is  we have first  to identify the various realm  overload use cases and see those actually justifying to add new mechanisms.


2)      I share Ulrich's questions  on how to deal with realm overload. Steve's  answer introduces a high complexity about detecting , evaluate the realm overload  and then which DA are acting etc. The fact to consider many of these points out of the scope does not suppress this complexity (which in addition occurs in an overloaded environment...) . So  I come back to my point 1 about the use cases to address  and the use of the mechanisms for server and DA overload

Best regards

JJacques


De : DiME [mailto:[e-mail]] De la part de Steve Donovan
Envoyé : mardi 18 février 2014 15:55
À : Wiehe, Ulrich (NSN - DE/Munich); [e-mail]
Objet : Re: [Dime] [dime] #34: Semantics of OC-Report-Type AVP

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]<mailto:[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