[Dime] diameter overload protection
"Poscic, Kristian (Kristian)" <kristian.poscic@alcatel-lucent.com> Tue, 17 December 2013 01:05 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 0BA931ADF90 for <dime@ietfa.amsl.com>; Mon, 16 Dec 2013 17:05:40 -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 qYPv4euuszJc for <dime@ietfa.amsl.com>; Mon, 16 Dec 2013 17:05:37 -0800 (PST)
Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 1364A1ADFD6 for <dime@ietf.org>; Mon, 16 Dec 2013 17:05:30 -0800 (PST)
Received: from us70uusmtp4.zam.alcatel-lucent.com (h135-5-2-66.lucent.com [135.5.2.66]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id rBH15SW9005471 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dime@ietf.org>; Mon, 16 Dec 2013 19:05:28 -0600 (CST)
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (us70twxchhub03.zam.alcatel-lucent.com [135.5.2.35]) by us70uusmtp4.zam.alcatel-lucent.com (GMO) with ESMTP id rBH15Sma000892 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Mon, 16 Dec 2013 20:05:28 -0500
Received: from US70UWXCHMBA05.zam.alcatel-lucent.com ([169.254.10.36]) by US70TWXCHHUB03.zam.alcatel-lucent.com ([135.5.2.35]) with mapi id 14.02.0247.003; Mon, 16 Dec 2013 20:05:28 -0500
From: "Poscic, Kristian (Kristian)" <kristian.poscic@alcatel-lucent.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: diameter overload protection
Thread-Index: Ac76wsQ8yoNHBVHUT3itLREA+CwZzg==
Date: Tue, 17 Dec 2013 01:05:27 +0000
Message-ID: <7921F977B17D5B49B8DCC955A339D2F02ACC8A68@US70UWXCHMBA05.zam.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_7921F977B17D5B49B8DCC955A339D2F02ACC8A68US70UWXCHMBA05z_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
Subject: [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 01:05:40 -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
- [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)