Re: [Dime] Issue#31 status
"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Tue, 25 March 2014 10:21 UTC
Return-Path: <ulrich.wiehe@nsn.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 D68631A0181 for <dime@ietfa.amsl.com>; Tue, 25 Mar 2014 03:21:45 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001] 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 psF-szky0kVA for <dime@ietfa.amsl.com>; Tue, 25 Mar 2014 03:21:41 -0700 (PDT)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 6E89E1A017B for <dime@ietf.org>; Tue, 25 Mar 2014 03:21:41 -0700 (PDT)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.14.3/8.14.3) with ESMTP id s2PALcDt011369 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Mar 2014 10:21:38 GMT
Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s2PALc3A016847 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Mar 2014 11:21:38 +0100
Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 25 Mar 2014 11:21:38 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.91]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Tue, 25 Mar 2014 11:21:38 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] Issue#31 status
Thread-Index: Ac8tfUYIV82WBUGEQQ+YDsLcVKoJfQaH0FqAAB0AC2A=
Date: Tue, 25 Mar 2014 10:21:37 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151D20E8@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151B3CF7@DEMUMBX014.nsn-intra.net> <53309E4F.7050509@usdonovans.com>
In-Reply-To: <53309E4F.7050509@usdonovans.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.112]
Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151D20E8DEMUMBX014nsnin_"
MIME-Version: 1.0
X-purgate-type: clean
X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de
X-purgate: clean
X-purgate: This mail is considered clean (visit http://www.eleven.de for further information)
X-purgate-size: 25727
X-purgate-ID: 151667::1395742899-0000137C-05BAA2A7/0/0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/c2R8YIO1wGxebvXyQcNZE1ZW3Gk
Subject: Re: [Dime] Issue#31 status
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, 25 Mar 2014 10:21:46 -0000
Steve, I think we can easily extend the proposed text for #56 to cover these points: 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) Overload Control States for reporting nodes containing a validity duration of 0 sec. should not expire before any previously sent (stale) OLR has timed out at any reacting node. 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. Reacting nodes do not delete an OCS when receiving an answer message that does not contain an OC-OLR AVP (i.e. absence of OLR means "no change"). 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. From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan Sent: Monday, March 24, 2014 10:06 PM To: dime@ietf.org Subject: Re: [Dime] Issue#31 status All, Can someone boil down the various proposed wording for this issue into what we want to have in the -02 draft. Thanks, Steve On 2/19/14 8:17 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote: #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling Dear all, I did not receive much support for the proposal to define an OC-Ongoing-Throttling-Info AVP in request messages that survived a throttlting. However, we seem to agree on some principles: Missing OLR in answer means "no change"; it does not mean "no overload/no throttling requested" Reporting nodes SHOULD include OLR in every answer that it sends in response to a request message which indicated OLR_DEFAULT_ALGO support unless the reporting node has very good reasons not to do so. Exact wording is not yet agreed. Ulrich _______________________________________________ DiME mailing list DiME@ietf.org<mailto:DiME@ietf.org> https://www.ietf.org/mailman/listinfo/dime
- [Dime] Issue#31 status Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] Issue#31 status Steve Donovan
- Re: [Dime] Issue#31 status Ben Campbell
- Re: [Dime] Issue#31 status Steve Donovan
- Re: [Dime] Issue#31 status Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] Issue#31 status Steve Donovan