Re: [Dime] [dime] #56: Bad Description of Overload Control State
"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Tue, 25 February 2014 09:04 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 75C1C1A03C5 for <dime@ietfa.amsl.com>; Tue, 25 Feb 2014 01:04:47 -0800 (PST)
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 bnRPraNlftsB for <dime@ietfa.amsl.com>; Tue, 25 Feb 2014 01:04:44 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id C86BE1A033F for <dime@ietf.org>; Tue, 25 Feb 2014 01:04:43 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1P93lH8018460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 10:04:40 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1P93jd3023882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 10:03:46 +0100
Received: from DEMUHTC006.nsn-intra.net (10.159.42.37) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 25 Feb 2014 10:03:45 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC006.nsn-intra.net ([10.159.42.37]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 10:03:44 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>, "dime@ietf.org" <dime@ietf.org>, "draft-docdt-dime-ovli@tools.ietf.org" <draft-docdt-dime-ovli@tools.ietf.org>
Thread-Topic: [dime] #56: Bad Description of Overload Control State
Thread-Index: AQHPLKXn/K5opEUqEkqiVdwfHsd6G5rEUNjAgABMwyCAARmykA==
Date: Tue, 25 Feb 2014 09:03:44 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B462A@DEMUMBX014.nsn-intra.net>
References: <062.3b2a6cd77559639b8e7a22c978bd41db@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D9000668151B43DE@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209784A7E@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B9209784A7E@ESESSMB101.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.116]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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: 6879
X-purgate-ID: 151667::1393319080-00005322-9D676A3D/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/XMIUJ8HnrzsNW6WZleQdaQbHig8
Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State
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 Feb 2014 09:04:47 -0000
Hi MCruz, thank you for your comments. I agree that there are dependencies withh issue#35. Best regards Ulrich -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Maria Cruz Bartolome Sent: Monday, February 24, 2014 5:23 PM To: dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State Ulrich, In your proposal you newly define overload control states per client/origin-host. This is very related to the ongoing discussion in Issue#35. Then, at least I think we need to first conclude on that thread. A part from that, we need to take into account that 3GPP requirement on overload mitigation differentiation per client is a server option: TR 29809 ch. 6.4.7.1 states "It may be up to the server/agent implementations to decide when and whether overload mitigation differentiation per client is used". Therefore, it could be better to keep this differentiation per client/origin-host out of chapter 5.5.1. Best regards /MCruz -----Original Message----- From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich) Sent: lunes, 24 de febrero de 2014 12:44 To: dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State There has been no discussion of this ticket. I propose to replace text in claues 5.5.1 as suggested in the ticket. Regards Ulrich -----Original Message----- From: ext dime issue tracker [mailto:trac+dime@grenache.tools.ietf.org] Sent: Tuesday, February 18, 2014 1:35 PM To: draft-docdt-dime-ovli@tools.ietf.org; Wiehe, Ulrich (NSN - DE/Munich) Cc: dime@ietf.org Subject: [dime] #56: Bad Description of Overload Control State #56: Bad Description of Overload Control State The description of Overload Control State in clause 5.5.1 is inaccurate, incomplete and could be misleading. It does not differentiate between Overload Control State in a reacting node versus Overload Control State in a reporting node. It also does not describe how Overload Control States are maintained. It is proposed to replace current text with the following: 5.5.1. Overload Control State (OCS) 5.5.1.1 Overload Control States for reacting nodes A reacting node (client) 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 toward 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 information as shown in table 1/table 2. <see attachment> Agents that take the role of a reacting node on behalf of clients MUST maintain Overload Control States per client. 5.5.1.2 Overload Control States for reporting nodes A reporting node (server) maintains per supported Diameter application an Overload Control State for each Origin-Host from which it receives requests that contain an (explicit or implicit) indication of OLR_DEFAULT_ALGO support. A reporting node (agent that is configured to take the role of a reporting node for a given realm) maintains per supported Diameter application an Overload Control State for each Origin-Host from which it receives realm-type requests (of that given realm) that contain an (explicit or implicit) indication of OLR_DEFAULT_ALGO support. A Overload Control State may be identified by the pair of Application- Id and Origin-Host. The Overload Control State for a given pair of Application and Origin- Host could include the information as shown in table 3. <see attachment> Note: For nodes that support other features than just OLR_DEFAULT_ALGO the Overload Control State definitions may need to be extended. 5.5.1.3 Maintaining Overload Control States Reacting nodes create a host-type OCS with OCS-Id = (x,A) when receiving an answer message of application x containing an Orig-Host of A and a host-type OC-OLR AVP unless such host-type OCS already exists. Reacting nodes create a realm-type OCS with OCS-Id = (x,A) when receiving an answer message of application x containing an Orig-Realm of A 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 with OCS-Id = (x,A) when receiving an answer message of application x containing an Orig-Host of A and a host-type OC-OLR AVP with a sequence number higher than the stored sequence number. Reacting nodes update the realm-type OCS with OCS-Id = (x,A) when receiving an answer message of application x containing an Orig-Realm of A and a realm-type OC-OLR AVP with a sequence number higher than the stored sequence number. Reporting nodes create an OCS with OCS-Id = (x,A) when receiving a request (indicating support of OLR_DEFAULT_ALGO) of application x containing an Orig-Host of A unless such OCS already exists. Reporting nodes delete an OCS when it expires. Reporting nodes update the OCS with OCS-Id = (x,A) when they detect the need to modify the requested amount of application x traffic reduction generated by A. -- -------------------------+---------------------------------------------- -------------------------+--- Reporter: | Owner: draft-docdt-dime- ulrich.wiehe@nsn.com | ovli@tools.ietf.org Type: defect | Status: new Priority: major | Milestone: Component: draft- | Version: docdt-dime-ovli | Keywords: Severity: Active WG | Document | -------------------------+---------------------------------------------- -------------------------+--- Ticket URL: <http://trac.tools.ietf.org/wg/dime/trac/ticket/56> dime <http://tools.ietf.org/wg/dime/> _______________________________________________ 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] [dime] #56: Bad Description of Overload Co… dime issue tracker
- Re: [Dime] [dime] #56: Bad Description of Overloa… Steve Donovan
- Re: [Dime] [dime] #56: Bad Description of Overloa… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] [dime] #56: Bad Description of Overloa… Maria Cruz Bartolome
- Re: [Dime] [dime] #56: Bad Description of Overloa… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] [dime] #56: Bad Description of Overloa… Wiehe, Ulrich (NSN - DE/Munich)
- Re: [Dime] [dime] #56: Bad Description of Overloa… Jouni Korhonen
- Re: [Dime] [dime] #56 (draft-docdt-dime-ovli): Ba… dime issue tracker
- Re: [Dime] [dime] #56 (draft-ietf-dime-ovli): Bad… dime issue tracker