Re: [Dime] issue #56 proposed conclusion
"TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com> Wed, 26 March 2014 07:56 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 970C01A02D1 for <dime@ietfa.amsl.com>; Wed, 26 Mar 2014 00:56:13 -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 qMwnEF_bg0TU for <dime@ietfa.amsl.com>; Wed, 26 Mar 2014 00:56:11 -0700 (PDT)
Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 226611A02CB for <dime@ietf.org>; Wed, 26 Mar 2014 00:56:10 -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 s2Q7u74C006780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <dime@ietf.org>; Wed, 26 Mar 2014 02:56:08 -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 s2Q7u6vM002371 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <dime@ietf.org>; Wed, 26 Mar 2014 08:56:06 +0100
Received: from FR712WXCHMBA12.zeu.alcatel-lucent.com ([169.254.8.152]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Wed, 26 Mar 2014 08:56:06 +0100
From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" <jean-jacques.trottin@alcatel-lucent.com>
To: "dime@ietf.org" <dime@ietf.org>
Thread-Topic: issue #56 proposed conclusion
Thread-Index: Ac9EPXt5r7PuIO0xQGuIoXMHDH01dgDR2ZtAAAD7zKAAHYCmoAAxWkVQ
Date: Wed, 26 Mar 2014 07:56:06 +0000
Message-ID: <E194C2E18676714DACA9C3A2516265D202678566@FR712WXCHMBA12.zeu.alcatel-lucent.com>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151D1F0A@DEMUMBX014.nsn-intra.net> <E194C2E18676714DACA9C3A2516265D202672A0A@FR712WXCHMBA12.zeu.alcatel-lucent.com> <5BCBA1FC2B7F0B4C9D935572D9000668151D2014@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151D2014@DEMUMBX014.nsn-intra.net>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.239.27.38]
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/giwFPe23R2tvxeqQ6v-HUr4-l88
Subject: Re: [Dime] issue #56 proposed conclusion
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: Wed, 26 Mar 2014 07:56:13 -0000
Hi Ulrich I agree with your example: so with an OCS that can be defined per application and algorithm. Nevertheless a remark, I think this OCS exists only when the algorithm has been selected. I do not see the case of an OCS with a supported but not selected algorithm. I may miss something. So wording in 5.5.1.2 could be: A reporting node maintains per supported Diameter application and per selected Abatement Algorithm an Overload Control State.... This does not remove my questioning about the per client case: pease see the other mail Best regards JJacques -----Message d'origine----- De : Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Envoyé : mardi 25 mars 2014 09:08 À : TROTTIN, JEAN-JACQUES (JEAN-JACQUES); dime@ietf.org Objet : RE: issue #56 proposed conclusion Hi JJacques, let me try to give an example: Client C1 supports algorithms A1 and A2. Server S supports algorithms A1 and A2. Client C2 supports only algorithm A1. C1 sends an application x request indicating support of A1 and A2 to the server S. Now S selects one single algorithm (in this example A2) and requests some reduction using A2. S has a OCS identified by the pair (x,A2). Now client C2 sends an application x request indicating support of A1 to S. Again S selects one single algorithm (in this case A1) and requests some reduction using A1. S has an OCS identified by the pair (x,A1). In summary it is right that S selects one single algorithm out of the set of adveritzed algorithms, but this does not mean that S must only maintain one OCS. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext TROTTIN, JEAN-JACQUES (JEAN-JACQUES) Sent: Monday, March 24, 2014 7:08 PM To: dime@ietf.org Subject: Re: [Dime] issue #56 proposed conclusion Hi Ulrich In 5.5.1.2 you wrote: A reporting node maintains per supported Diameter application and per supported (and eventually selected) Abatement Algorithm an Overload Control State but for another ticket, there is the conclusion that reporting node selects one algorithm, so your wording would become ...per supported Diameter application and for the selected Abatement Algorithm.... I have also the question of the mitigation for a given client which may drives the reporting node to consider a state for a client Interest of this text is that it clarifies the node behaviors. Best regards JJacques -----Message d'origine----- De : DiME [mailto:dime-bounces@ietf.org] De la part de Wiehe, Ulrich (NSN - DE/Munich) Envoyé : lundi 24 mars 2014 18:24 À : Wiehe, Ulrich (NSN - DE/Munich); dime@ietf.org Objet : Re: [Dime] issue #56 proposed conclusion Dear all, I have received a further comment asking not to abbreviate "Overload Control State" as OCS is used for "Online Charging System". I'm fine with not abbreviating "Overload Control State". I shall close issue #56 to meet Steve's deadline for the 02-draft, unless I receive more comments by tomorrow. Ulrich -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) Sent: Thursday, March 20, 2014 2:08 PM To: dime@ietf.org Subject: issue #56 proposed conclusion #56: Bad Description of Overload Control State Dear all, I have received comments from Steve, MCruz and Jouni. I believe all comments are covered by the following proposed text: 5.5.1. Overload Control State (OCS) 5.5.1.1 Overload Control States for reacting nodes A reacting node maintains per supported Diameter application - a host-type Overload Control State for each Destination-Host towards which it sends host-type requests and - a realm-type Overload Control State for each Destination-Realm towards which it sends realm-type requests. A host-type Overload Control State may be identified by the pair of Application-Id and Destination-Host. A realm-type Overload Control State may be identified by the pair of Application-Id and Destination-Realm. The host-type/realm-type Overload Control State for a given pair of Application and Destination-Host / Destination-Realm could include the following information: - Sequence number (as reveived in OC-OLR) - Time of expiry (deviated from validity duration as received in OC-OLR and time of reception) - Selected Abatement Algorithm (as received in OC-Supported-Features) - Algorithm specific input data (as received within OC-OLR, e.g. Reduction Percentage for Loss) 5.5.1.2 Overload Control States for reporting nodes A reporting node maintains per supported Diameter application and per supported (and eventually selected) Abatement Algorithm an Overload Control State. An Overload Control State may be identified by the pair of Application-Id and supported Abatement Algorithm. The Overload Control State for a given pair of Application and Abatement Algorithm could include the information: - Sequence number - Validity Duration and Expiry Time - Algorithm specific input data (e.g. Reduction Percentage for Loss) 5.5.1.3 Maintaining Overload Control States Reacting nodes create a host-type OCS identified by OCS-Id = (app-id,host-id) when receiving an answer message of application app-id containing an Orig-Host of host-id and a host-type OC-OLR AVP unless such host-type OCS already exists. Reacting nodes create a realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving an answer message of application app-id containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP unless such realm type OCS already exists. Reacting nodes delete an OCS when it expires (i.e. when current time minus reception time is greater than validity duration). Reacting nodes update the host-type OCS identified by OCS-Id = (app-id,host-id) when receiving an answer message of application app-id containing an Orig-Host of host-id and a host-type OC-OLR AVP with a sequence number higher than the stored sequence number. Reacting nodes update the realm-type OCS identified by OCS-Id = (app-id,realm-id) when receiving an answer message of application app-id containing an Orig-Realm of realm-id and a realm-type OC-OLR AVP with a sequence number higher than the stored sequence number. Reporting nodes create an OCS identified by OCS-Id = (app-id,Alg) when receiving a request of application app-id containing an OC-Supported-Features AVP indicating support of the Abatement Algorithm Alg (which the reporting node selects) while being overloaded, unless such OCS already exists. Reporting nodes delete an OCS when it expires. Reporting nodes update the OCS identified by OCS-Id = (app-id,Alg) when they detect the need to modify the requested amount of application app-id traffic reduction. Ulrich _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime
- [Dime] issue #56 proposed conclusion Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] issue #56 proposed conclusion Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] issue #56 proposed conclusion TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] issue #56 proposed conclusion TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] issue #56 proposed conclusion Steve Donovan
- Re: [Dime] issue #56 proposed conclusion Steve Donovan
- Re: [Dime] issue #56 proposed conclusion Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] issue #56 proposed conclusion Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] issue #56 proposed conclusion Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] issue #56 proposed conclusion Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] issue #56 proposed conclusion TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] issue #56 proposed conclusion Steve Donovan
- Re: [Dime] issue #56 proposed conclusion Steve Donovan
- Re: [Dime] issue #56 proposed conclusion Steve Donovan
- Re: [Dime] issue #56 proposed conclusion TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] issue #56 proposed conclusion TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] issue #56 proposed conclusion Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] issue #56 proposed conclusion TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] issue #56 proposed conclusion Steve Donovan
- Re: [Dime] issue #56 proposed conclusion Steve Donovan
- Re: [Dime] issue #56 proposed conclusion Steve Donovan
- Re: [Dime] issue #56 proposed conclusion TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] issue #56 proposed conclusion Steve Donovan
- Re: [Dime] issue #56 proposed conclusion TROTTIN, JEAN-JACQUES (JEAN-JACQUES)
- Re: [Dime] issue #56 proposed conclusion Steve Donovan