Re: [Dime] diameter overload protection
"TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> Tue, 17 December 2013 08:12 UTC
Return-Path: <jean-jacques.trottin@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 04E2B1AE0F3 for <dime@ietfa.amsl.com>; Tue, 17 Dec 2013 00:12:50 -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 m2K64uFRxUUw for <dime@ietfa.amsl.com>; Tue, 17 Dec 2013 00:12:46 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id C54321AE0EF for <dime@ietf.org>; Tue, 17 Dec 2013 00:12:46 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com [135.239.2.42]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rBH8CdBl009632 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dime@ietf.org>; Tue, 17 Dec 2013 02:12:40 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rBH8CaKw015005 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Tue, 17 Dec 2013 09:12:39 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.241]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.02.0247.003; Tue, 17 Dec 2013 09:12:37 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com>
To: "Poscic, Kristian (Kristian)" <kristian.poscic@alcatel-lucent.com>, "dime@ietf.org list" <dime@ietf.org>
Thread-Topic: diameter overload protection
Thread-Index: Ac76wsQ8yoNHBVHUT3itLREA+CwZzgAOYXog
Date: Tue, 17 Dec 2013 08:12:36 +0000
Message-ID: <E194C2E18676714DACA9C3A2516265D201CB5B9A@FR712WXCHMBA12.zeu.alcatel-lucent.com>
References: <7921F977B17D5B49B8DCC955A339D2F02ACC8A68@US70UWXCHMBA05.zam.alcatel-lucent.com>
In-Reply-To: <7921F977B17D5B49B8DCC955A339D2F02ACC8A68@US70UWXCHMBA05.zam.alcatel-lucent.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.39]
Content-Type: multipart/alternative; boundary="_000_E194C2E18676714DACA9C3A2516265D201CB5B9AFR712WXCHMBA12z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
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 08:12:50 -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:dime-bounces@ietf.org] De la part de Poscic, Kristian (Kristian) Envoyé : mardi 17 décembre 2013 02:05 À : 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)