Subject: [Dime] diameter overload protection

From: "Poscic, Kristian (Kristian)" <[email-masked]>
Date: Tue, 17 Dec 2013 01:05:27 +0000

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

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Tue, 17 Dec 2013 08:12:36 +0000

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:[email-masked]] De la part de Poscic, Kristian (Kristian)
Envoyé : mardi 17 décembre 2013 02:05
À : [email-masked]
Objet : [Dime] diameter overload protection

Hi,

---

From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <[email-masked]>
Date: Tue, 17 Dec 2013 08:54:36 +0000

In 5.5.2 Reacting nodes consideration., it is well mentioned that the OLR applies to the Host identified by Origin-Host AVP or the  Realm identified by Origin-Realm AVP., but nothing is said about the Diameter Application identified  by the Application ID, so I propose, to add the following paragraph in 5.5.2 :

The reacting node learns the Diameter application to which the overload report applies from the Application-ID of the answer message containing the OC-OLR AVP.

This paragraph  can be inserted just before the hereafter  existing paragraph
   From the OC-Report-Type AVP the reacting node learns whether the
   overload condition report concerns a specific host (as identified by
   the Origin-Host AVP of the answer message containing the OC-OLR AVP)
   or the entire realm (as identified by the Origin-Realm AVP of the
   answer message containing the OC-OLR AVP).

Best regards

JJacques

---

From: Jouni <[email-masked]>
Date: Tue, 17 Dec 2013 11:53:46 +0200

Good point. Will clarify.

On Dec 17, 2013, at 10:54 AM, TROTTIN, JEAN-JACQUES (JEAN-JACQUES) wrote:

> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: "Poscic, Kristian (Kristian)" <[email-masked]>
Date: Tue, 17 Dec 2013 17:52:15 +0000

Ok, makes sense. Thanks JJ.

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

Hi Kristian and  all

Best regards

JJacques

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

Hi,