Re: [Dime] [dime] #41 (draft-docdt-dime-ovli): Need better overview
"TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> Mon, 24 March 2014 15:41 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 71A161A0255 for <dime@ietfa.amsl.com>; Mon, 24 Mar 2014 08:41:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1ynGYYrqwSR5 for <dime@ietfa.amsl.com>; Mon, 24 Mar 2014 08:41:32 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id AD3351A0257 for <dime@ietf.org>; Mon, 24 Mar 2014 08:41:32 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s2OFfUAX014902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dime@ietf.org>; Mon, 24 Mar 2014 10:41:31 -0500 (CDT)
Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s2OFfT77014269 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Mon, 24 Mar 2014 16:41:29 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.164]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Mon, 24 Mar 2014 16:41:29 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] [dime] #41 (draft-docdt-dime-ovli): Need better overview
Thread-Index: AQHPR2R/UJRKPJ1EBkG4tvNtsb1kxZrwXHQw
Date: Mon, 24 Mar 2014 15:41:29 +0000
Message-ID: <E194C2E18676714DACA9C3A2516265D20267290F@FR712WXCHMBA12.zeu.alcatel-lucent.com>
References: <057.4fed1570cbb27d114428d8cc6fe5dcd2@trac.tools.ietf.org> <072.d5e30cfd5cc5ac461bc3774ad9853b2b@trac.tools.ietf.org>
In-Reply-To: <072.d5e30cfd5cc5ac461bc3774ad9853b2b@trac.tools.ietf.org>
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/1SeLVD3XhkEjii473nHLo6NtX78
Subject: Re: [Dime] [dime] #41 (draft-docdt-dime-ovli): Need better overview
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: Mon, 24 Mar 2014 15:41:35 -0000
Hi Steve I am oK on your text apart a few sentences on the realm overload for which for me we have not yet concluded (cf my to day mail in the thread [Dime] Resolution on action to discuss the need for Realm-Routed-Reports. This is about this paragraph and especially the word "entire": On the other hand, an "entire" Diameter realm may be overloaded, in which case such attempts would do harm. DOIC OLRs have a concept of "report type" (Section 4.6), where the type defines such behaviors. Report types are extensible. This document defines report types for overload of a specific server, and for overload of an "entire" realm. So I think a bit premature to insert this part of text as it is. Best regards JJacques -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de dime issue tracker Envoyé : lundi 24 mars 2014 14:24 À : draft-docdt-dime-ovli@tools.ietf.org; srdonovan@usdonovans.com Cc : dime@ietf.org Objet : Re: [Dime] [dime] #41 (draft-docdt-dime-ovli): Need better overview #41: Need better overview Changes (by srdonovan@usdonovans.com): * status: new => closed * resolution: => fixed Comment: The following wording for section 3.0 was added. A new issue will be opened to reflect that the remainder of section 3 needs to be made consistent with the current state of the DIOC solution. ----- The Diameter Overload Information Conveyance (DOIC) mechanism allows Diameter nodes to request other nodes to perform overload abatement actions, that is, actions to reduce the load offered to the overloaded node. A Diameter node that supports DOIC is known as a "DOIC endpoint". Any Diameter node can act as a DOIC endpoint, including clients, servers, and agents. DOIC endpoints are further divided into "Reporting Nodes" and "Reacting Nodes." A reporting node requests overload abatement by sending an Overload Report (OLR) to one or more reacting nodes. A reacting node consumes OLRs, and performs whatever actions are needed to fulfill the requests. A Reporting node may report overload on its own behalf, or on behalf of other (typically upstream) nodes. Likewise, a reacting node may perform overload abatement on its own behalf, or on behalf of other (typically downstream) nodes. A node's role as a DOIC endpoint is independent of its Diameter role. For example, Diameter relay and proxy agents may act as DOIC endpoints, even though they are not endpoints in the Diameter sense. Since Diameter enables bi-directional applications, where Diameter servers can send requests towards Diameter clients, a given Diameter node can simultaneously act as a reporting node and reacting node. Likewise, an relay or proxy agent may act as a reacting node from the perspective of upstream nodes, and a reporting node from the perspective of downstream nodes. DOIC endpoints do not generate new messages to carry DOIC related information. Rather, they "piggyback" DOIC information over existing Diameter messages by inserting new AVPs into existing Diameter requests and responses. Nodes indicate support for DOIC, and any needed DOIC parameters by inserting an OC_Supported_Features AVP (Section 4.1) into existing requests and responses. Reporting nodes send OLRs by inserting OC-OLR AVPs. (Section 4.3) A given OLR applies to the Diameter realm and application of the Diameter message that carries it. If a reporting node supports more than one realm and/or application, it reports independently for each combination of realm and application. Similarly, OC-Feature-Vector AVPs apply to the realm and application of the enclosing message. This implies that a node may support DOIC for one application and/or realm, but not another, and may indicate different DOIC parameters for each application and realm for which it supports DOIC. Reacting nodes perform overload abatement according to an agreed-upon abatement algorithm. An abatement algorithm defines the meaning of the parameters of an OLR, and the procedures required for overload abatement. This document specifies a single must-support algorithm, namely the "loss" algorithm [ref?]. Future specifications may introduce new algorithms. Overload conditions may vary in scope. For example, a single Diameter node may be overloaded, in which case reacting nodes may reasonably attempt to send throttled requests to other destinations or via other agents. On the other hand, an entire Diameter realm may be overloaded, in which case such attempts would do harm. DOIC OLRs have a concept of "report type" (Section 4.6), where the type defines such behaviors. Report types are extensible. This document defines report types for overload of a specific server, and for overload of an entire realm. While a reporting node sends OLRs to "adjacent" reacting nodes, nodes that are "adjacent" for DOIC purposes may not be adjacent from a Diameter, or transport, perspective. For example, one or more Diameter agents that do not support DOIC may exist between a given pair of reporting and reacting nodes, as long as those agents pass unknown AVPs through unmolested. The report types described in this document can safely pass through non-supporting agents. This may not be true for report types defined in future specifications. Documents that introduce new report types MUST describe any limitations on their use across non-supporting agents. -- -------------------------+---------------------------------------------- -------------------------+--- Reporter: | Owner: draft-docdt-dime- ben@nostrum.com | ovli@tools.ietf.org Type: defect | Status: closed Priority: major | Milestone: Component: draft- | Version: 1.0 docdt-dime-ovli | Resolution: fixed Severity: Active WG | Document | Keywords: | -------------------------+---------------------------------------------- -------------------------+--- Ticket URL: <http://tools.ietf.org/wg/dime/trac/ticket/41#comment:1> dime <http://tools.ietf.org/wg/dime/> _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime
- [Dime] [dime] #41: Need better overview dime issue tracker
- Re: [Dime] [dime] #41: Need better overview lionel.morand
- Re: [Dime] [dime] #41: Need better overview Steve Donovan
- Re: [Dime] [dime] #41: Need better overview Ben Campbell
- Re: [Dime] [dime] #41: Need better overview lionel.morand
- Re: [Dime] [dime] #41 (draft-docdt-dime-ovli): Ne… dime issue tracker
- Re: [Dime] [dime] #41 (draft-docdt-dime-ovli): Ne… TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] [dime] #41 (draft-docdt-dime-ovli): Ne… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] [dime] #41 (draft-docdt-dime-ovli): Ne… Shishufeng (Susan)
- Re: [Dime] [dime] #41 (draft-ietf-dime-ovli): Nee… dime issue tracker