Re: [Dime] [dime] #56: Bad Description of Overload Control State

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Tue, 25 February 2014 09:23 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 37E9B1A0659 for <dime@ietfa.amsl.com>; Tue, 25 Feb 2014 01:23:00 -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 HxJp8v1sVQY7 for <dime@ietfa.amsl.com>; Tue, 25 Feb 2014 01:22:58 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id E62BD1A0654 for <dime@ietf.org>; Tue, 25 Feb 2014 01:22:57 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1P9I2Ur018771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 10:22:55 +0100
Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id s1P90dfl028258 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 10:00:41 +0100
Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 25 Feb 2014 10:00:40 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 10:00:40 +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] [dime] #56: Bad Description of Overload Control State
Thread-Index: AQHPLKXn/K5opEUqEkqiVdwfHsd6G5rEUNjAgABEvoCAARY+cA==
Date: Tue, 25 Feb 2014 09:00:40 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B461C@DEMUMBX014.nsn-intra.net>
References: <062.3b2a6cd77559639b8e7a22c978bd41db@trac.tools.ietf.org> <5BCBA1FC2B7F0B4C9D935572D9000668151B43DE@DEMUMBX014.nsn-intra.net> <530B7729.3010005@usdonovans.com>
In-Reply-To: <530B7729.3010005@usdonovans.com>
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="iso-8859-1"
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: 7469
X-purgate-ID: 151667::1393320175-00003660-F287E6C5/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/czHq3am12NKnI2jN1Fp1l_YquDg
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:23:00 -0000

Steve,

thank you for your comments.

Please see inline.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, February 24, 2014 5:45 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #56: Bad Description of Overload Control State

Ulrich,

See inline.

Steve
On 2/24/14 5:44 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
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

SRD> Why qualify with client.  It applies to all reacting nodes.
<Ulrich> I agree to remove "(client)"</Ulrich>


    a host-type Overload Control State for each Destination-Host towards
    which it sends host-type requests and a realm-type Overload Control
 State
SRD> ...and... (add the word and here)
<Ulrich> I do not agree </Ulrich>


    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>
SRD> Reception time and validity duration could be replaced with "expiration time"
<Ulrich> I agree </Ulrich>



    Agents that take the role of a reacting node on behalf of clients MUST
    maintain Overload Control States per client.
SRD> This depends on the resolution of the current discussion of issue 35.  I propose it be modified to "Agents that take the reacting node on behalf of non-supporting clients must maintain either the global overload state or per client overload state if requested by the reporting node.
<Ulrich> I agree that this depends on the outcome of #35 </Ulrich>



    5.5.1.2   Overload Control States for reporting nodes

    A reporting node (server) maintains per supported Diameter application
SRD> There is no reason to qualify the reporting node as a server.  It could also be an agent and all of this still applies.
<Ulrich> the agent case is described below (agent that is configured to take the role of a reporting node for a given realm) and there are differences </Ulrich> 

    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.
SRD> It doesn't need to be per Origin-Host, per the discussion of issue 35.  We should support a global overload state if the reporting node doesn't which to keep per reacting node state.
<Ulrich> I agree that this depends on the outcome of #35 </Ulrich>


    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.
SRD> I don't see this as a must.  It could be identified by just Application-ID.
<Ulrich> I agree that this depends on the outcome of #35 </Ulrich>


    The Overload Control State for a given pair of Application and Origin-
    Host could include the information as shown in table 3.
    <see attachment>
SRD> Expiration time should be sufficient.
<Ulrich> no, you need to store the validity duration since this will be sent in OLRs</Ulrich>


    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.
SRD> Why would the reporting node create an OCS when it is not overloaded?  Shouldn't this be modified to say that the reporting nodes creates an OCS when receiving a request and when in an overloaded state for the application?
<Ulrich> ok </Ulrich>

  Also, we should not require that the reporting node keep state for all reacting nodes, it should be able to keep a single state for all reacting nodes.
<Ulrich> I agree that this depends on the outcome of #35 </Ulrich>


    Reporting nodes delete an OCS when it expires.
SRD> or when the reporting node exits the overload state.  This should be after the reporting node sends an overload report with validity duration of zero to reacting nodes.
<Ulrich> there are dependencies with #31 and #35: once a single OLR with validity duration of zero is sent you should not delete the OCS as there may be other agents (issue #31) or even other clients (issue #35) that did not get the "end of overload indication"</Ulrich>


    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.