IETF Logo Mail Archive

Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Tue, 25 February 2014 07:51 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 25C731A044B for <dime@ietfa.amsl.com>; Mon, 24 Feb 2014 23:51:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.899
X-Spam-Level:
X-Spam-Status: No, score=-6.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 L1RJoWRXIw55 for <dime@ietfa.amsl.com>; Mon, 24 Feb 2014 23:51:52 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 7CD261A042C for <dime@ietf.org>; Mon, 24 Feb 2014 23:51:51 -0800 (PST)
Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id s1P7ot2r013412 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 25 Feb 2014 08:51:48 +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 s1P7orna004908 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 25 Feb 2014 08:50:54 +0100
Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Tue, 25 Feb 2014 08:50:53 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.242]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0123.003; Tue, 25 Feb 2014 08:50:53 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Steve Donovan <srdonovan@usdonovans.com>, 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] [dime] #57: Handling of "Realm-Routed" Overload report type
Thread-Index: AQHPMZF4/G9fUnj1okql3Ng2TYdVeZrEug2AgADbzjA=
Date: Tue, 25 Feb 2014 07:50:52 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151B45D9@DEMUMBX014.nsn-intra.net>
References: <066.89ca14db25e51cc9abb1531f0f99f646@trac.tools.ietf.org> <087A34937E64E74E848732CFF8354B9209784BB3@ESESSMB101.ericsson.se> <530B9E01.3050506@usdonovans.com>
In-Reply-To: <530B9E01.3050506@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: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151B45D9DEMUMBX014nsnin_"
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: 16504
X-purgate-ID: 151667::1393314708-00005322-B30009E5/0-0/0-0
Archived-At: http://mailarchive.ietf.org/arch/msg/dime/6hr9NJmQpmujMOYC2-XQMC3Ks0M
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type
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 07:51:56 -0000

Hi,
I agree with MCruz.

Principle is that the server never sends OLRs with a report type of realm-routed-request (exept the case where the server knows (i.e.is configured) that there is no other server in that realm).

Only agents that are configured to take the role of a reporting node for a realm will insert OLRs with report type of realm-routed-requests into answer messages and the content should be the aggregation of percentages as received in host type OLRs from all the servers in the realm.

Ulrich




From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Monday, February 24, 2014 8:31 PM
To: Maria Cruz Bartolome; dime@ietf.org; draft-docdt-dime-ovli@tools.ietf.org
Subject: Re: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type

Maria Cruz,

Thanks for the comments.  We obviously have a different understanding of the meaning of realm-routed-request report (new attempt at a name to try to make Ulrich happy :-) ).

My definition is that it is a report generated by the server when the server does not want to receive new sessions.

Your definition appears to be that it is a report generated by an agent (or a server is there are no agents in the network?) to indicate that the network need to handle fewer new sessions.

I actually think both cases apply but I don't think that an agent can generate a realm-routed-request report without knowing the status of servers and their ability to handle new Diameter sessions.

Note that I'm discussing this in the context of session-based applications.  This could also be applied to pseudo session based applications and applications that always rely on realm routed requests.

Everyone, which definition applies?

Steve
On 2/24/14 12:51 PM, Maria Cruz Bartolome wrote:

Steve,



See some comments below please.

/MCruz



-----Original Message-----

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of dime issue tracker

Sent: lunes, 24 de febrero de 2014 17:20

To: draft-docdt-dime-ovli@tools.ietf.org<mailto:draft-docdt-dime-ovli@tools.ietf.org>; srdonovan@usdonovans.com<mailto:srdonovan@usdonovans.com>

Cc: dime@ietf.org<mailto:dime@ietf.org>

Subject: [Dime] [dime] #57: Handling of "Realm-Routed" Overload report type



#57: Handling of "Realm-Routed" Overload report type



 I'm assuming the name of the realm overload report in the -01 version will

 be changed to realm-routed.  This issue applies independent of the actual

 name of the report.



 The current behavior assumed for the realm-routed report is that the

 reacting node, generally the client, will reduce the percentage of realm

 routed requests sent to the reporting node.



 This is actually bad behavior and could result in the client throttling

 traffic that could have been handled by the full set of servers for that

 Diameter application.

[MCruz] This can only happen if the agent has miscalculated the realm overload.



 Consider the case where there are n servers for a Diameter application and

 all of those server are able to handle any transaction for that

 application.



 When one of those servers becomes overloaded and wishes to decrease the

 number of new sessions, the primary use of realm-routed requests.  The

 server will generate an OLR of type realm-routed.

[MCruz] I do not agree. Servers do not generate Realm-routed reports.



 Assume in this case that the other servers are all healthy and able to

 handle new sessions.



 Clients will not have the knowledge that there are other servers in the

 network able to handle the new session and will have no choice but the

 throttle a percentage of the new session requests.  Even when these

 throttled requests could have been handled by any of the non overloaded

 servers.



 The proposal is to specify that realm-routed reports must be handled by

 DOIC-supporting agents.  Agents will understand if there are other servers

 able to handle the new session and, if so, can adjust the percentage of

 requests routed to the overloaded server.



 Agents that handle the realm-routed OLR must remove the request from the

 answer before relaying the answer to client.  This prevents the report

 from being acted on by either multiple agents (if multiple are in the

 path) or by an agent and a client.



 Clients that receive the realm-routed OLR must handle the OLR by

 throttling the requested percentage.

v2.23.0 | Report a Bug | By Email