Re: [Dime] diameter overload protection
"Poscic, Kristian (Kristian)" <kristian.poscic@alcatel-lucent.com> Tue, 17 December 2013 17:52 UTC
Return-Path: <kristian.poscic@alcatel-lucent.com>
X-Original-To: dime@ietfa.amsl.com
Delivered-To: dime@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE8991AE069 for <dime@ietfa.amsl.com>; Tue, 17 Dec 2013 09:52:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7ISd-oGjJml2 for <dime@ietfa.amsl.com>; Tue, 17 Dec 2013 09:52:20 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id EDD221ADE8A for <dime@ietf.org>; Tue, 17 Dec 2013 09:52:19 -0800 (PST)
Received: from us70tusmtp1.zam.alcatel-lucent.com (h135-5-2-63.lucent.com [135.5.2.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rBHHqH0G027425 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dime@ietf.org>; Tue, 17 Dec 2013 11:52:17 -0600 (CST)
Received: from US70TWXCHHUB04.zam.alcatel-lucent.com (us70twxchhub04.zam.alcatel-lucent.com [135.5.2.36]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id rBHHqGFA030640 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Tue, 17 Dec 2013 12:52:17 -0500
Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.36]) by US70TWXCHHUB04.zam.alcatel-lucent.com ([135.5.2.36]) with mapi id 14.02.0247.003; Tue, 17 Dec 2013 12:52:16 -0500
From: "Poscic, Kristian (Kristian)" <kristian.poscic@alcatel-lucent.com>
To: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com>, "dime@ietf.org list" <dime@ietf.org>
Thread-Topic: diameter overload protection
Thread-Index: Ac76wsQ8yoNHBVHUT3itLREA+CwZzgAOYXogABUTZnA=
Date: Tue, 17 Dec 2013 17:52:15 +0000
Message-ID: <7921F977B17D5B49B8DCC955A339D2F02ACC9683@US70UWXCHMBA05.zam.alcatel-lucent.com>
References: <7921F977B17D5B49B8DCC955A339D2F02ACC8A68@US70UWXCHMBA05.zam.alcatel-lucent.com> <E194C2E18676714DACA9C3A2516265D201CB5B9A@FR712WXCHMBA12.zeu.alcatel-lucent.com>
In-Reply-To: <E194C2E18676714DACA9C3A2516265D201CB5B9A@FR712WXCHMBA12.zeu.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.5.27.16]
Content-Type: multipart/alternative; boundary="_000_7921F977B17D5B49B8DCC955A339D2F02ACC9683US70UWXCHMBA05z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Subject: Re: [Dime] diameter overload protection
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 17 Dec 2013 17:52:23 -0000
Ok, makes sense. Thanks JJ. From: TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Sent: Tuesday, December 17, 2013 12:13 AM To: Poscic, Kristian (Kristian); dime@ietf.org 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:dime-bounces@ietf.org] De la part de Poscic, Kristian (Kristian) Envoyé : mardi 17 décembre 2013 02:05 À : dime@ietf.org<mailto:dime@ietf.org> 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
- [Dime] diameter overload protection Poscic, Kristian (Kristian)
- Re: [Dime] diameter overload protection TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- [Dime] DOIC Section 5.5.2 Diameter application TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] DOIC Section 5.5.2 Diameter application Jouni
- Re: [Dime] diameter overload protection Poscic, Kristian (Kristian)