Re: [Dime] diameter overload protection

["Poscic, Kristian (Kristian)" <[e-mail]>]

Ok, makes sense. Thanks JJ.

From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
Sent: Tuesday, December 17, 2013 12:13 AM
To: Poscic, Kristian (Kristian); [e-mail] list
Subject: RE: diameter overload protection

Hi Kristian and  all

The main principle is that overload reports (OLR) are send from a reporting node (eg a server)   to a reacting node (eg a client) for a given Diameter application (eg Gx) with a traffic % reduction that the reacting node  will apply to the traffic it sends to this reporting node.  In addition we have the realm OLR that address a traffic  reduction to apply to requests sent  to a realm when the server  is not known. About piggybacking, the above described OLRs  are conveyed  in the Diameter answers between the concerned  server (or realm) and client for  a given Diameter application , and does not depend of the Diameter session
This resume the baseline mechanism   aimed in the draft, given that extensibility facilities are included to allow future extensions according to new requirements.

Regarding  your  remark that the % of reduction may apply to the traffic of  a Diameter session , this option was evocated  at the beginning of Diameter overlaod  discussions. This option  is not part of the baseline mechanism described  in this draft as having a too fine granularity and as you indicated diminishing the  efficiency of the overload control.  This option may be studied again in the future if there are relevant t requirements for it.

We will check and possibly review the wording of the draft  to avoid any ambiguity on the above.

Best regards


JJacques



De : DiME [mailto:[e-mail]] De la part de Poscic, Kristian (Kristian)
Envoyé : mardi 17 décembre 2013 02:05
À : [e-mail]<mailto:[e-mail]>
Objet : [Dime] diameter overload protection

Hi,
I've been reading through the draft-docdt-dime-ovli-01<http://datatracker.ietf.org/doc/draft-docdt-dime-ovli/> draft and would appreciate one clarification.
I know that a lot of discussions has been going on about the exact mechanisms and treatment of the AVPs but I'm missing something more basic.

It seems like that the draft suggests that for session aware applications (I'm interested in Gx application in particular), the mechanism relies on the reporting node to send the overload capability and indication over a session (piggybacking).
Does this mean that the reacting node throttles traffic for all Gx sessions destined to the dest-host/realm (as reported in ReportType), or only the traffic for that particular session over the report is received.
I would imagine that the reacting node would need to throttle all traffic (otherwise the overload protection mechanism would be greatly diminished), although this seems very unnatural - to receive the request over a single session but the action should be applied to all sessions.
Thanks,
Kris