Re: [Dime] diameter overload protection

"Poscic, Kristian (Kristian)" <> Tue, 17 December 2013 17:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EE8991AE069 for <>; Tue, 17 Dec 2013 09:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 7ISd-oGjJml2 for <>; Tue, 17 Dec 2013 09:52:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id EDD221ADE8A for <>; Tue, 17 Dec 2013 09:52:19 -0800 (PST)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id rBHHqH0G027425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <>; Tue, 17 Dec 2013 11:52:17 -0600 (CST)
Received: from ( []) by (GMO) with ESMTP id rBHHqGFA030640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <>; Tue, 17 Dec 2013 12:52:17 -0500
Received: from ([]) by ([]) with mapi id 14.02.0247.003; Tue, 17 Dec 2013 12:52:16 -0500
From: "Poscic, Kristian (Kristian)" <>
Thread-Topic: diameter overload protection
Thread-Index: Ac76wsQ8yoNHBVHUT3itLREA+CwZzgAOYXogABUTZnA=
Date: Tue, 17 Dec 2013 17:52:15 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02ACC9683US70UWXCHMBA05z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on
Subject: Re: [Dime] diameter overload protection
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 17 Dec 2013 17:52:23 -0000

Ok, makes sense. Thanks JJ.

Sent: Tuesday, December 17, 2013 12:13 AM
To: Poscic, Kristian (Kristian); 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


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

I've been reading through the draft-docdt-dime-ovli-01<> 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.