IETF Logo Mail Archive

Re: [Dime] Ongoing Throttling Information in request messages

"Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com> Wed, 27 November 2013 16:48 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 78ABA1AC85E for <dime@ietfa.amsl.com>; Wed, 27 Nov 2013 08:48:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] 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 CPueob4Pur_E for <dime@ietfa.amsl.com>; Wed, 27 Nov 2013 08:48:11 -0800 (PST)
Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB4D1AC829 for <dime@ietf.org>; Wed, 27 Nov 2013 08:48:10 -0800 (PST)
Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rARGm7lh024637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Nov 2013 17:48:07 +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 rARGm7UB011107 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 17:48:07 +0100
Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 27 Nov 2013 17:48:06 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 17:48:06 +0100
From: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>
To: ext Ben Campbell <ben@nostrum.com>
Thread-Topic: [Dime] Ongoing Throttling Information in request messages
Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQAnWH+wAADoRNAABgE0oAAA57DwAACoAlAAASWEQAAAqKUAACDdWeAAAz9GUAABLecQAA4Qc8ABE6PKsABJVfJQASwtPKABPWkoAAAbAcmAAAiCAgAAAnGc4A==
Date: Wed, 27 Nov 2013 16:48:06 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519BAFF@DEMUMBX014.nsn-intra.net>
References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> <A9CA33BB78081F478946E4F34BF9AAA014CF3131@xmb-rcd-x10.cisco.com> <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> <A9CA33BB78081F478946E4F34BF9AAA014CF31E9@xmb-rcd-x10.cisco.com> <5BCBA1FC2B7F0B4C9D935572D900066815192B90@DEMUMBX014.nsn-intra.net> <A9CA33BB78081F478946E4F34BF9AAA014CF3237@xmb-rcd-x10.cisco.com> <5BCBA1FC2B7F0B4C9D935572D900066815192BF7@DEMUMBX014.nsn-intra.net> <A9CA33BB78081F478946E4F34BF9AAA014CF32CD@xmb-rcd-x10.cisco.com> <5BCBA1FC2B7F0B4C9D935572D900066815192CD2@DEMUMBX014.nsn-intra.net> <A9CA33BB78081F478946E4F34BF9AAA014CF4801@xmb-rcd-x10.cisco.com> <5BCBA1FC2B7F0B4C9D935572D900066815192D5F@DEMUMBX014.nsn-intra.net> <A9CA33BB78081F478946E4F34BF9AAA014CF4BF3@xmb-rcd-x10.cisco.com> <5BCBA1FC2B7F0B4C9D935572D90006681519337D@DEMUMBX014.nsn-intra.net> <A9CA33BB78081F478946E4F34BF9AAA014D13546@xmb-rcd-x10.cisco.com> <5BCBA1FC2B7F0B4C9D935572D900066815193EFD@DEMU! ! MBX014.nsn-intra.net> <AB2686C7-478B-4874-9228-8314DD363815@nostrum.com> <5BCBA1FC2B7F0B4C9D935572D90006681519B9C8@DEMUMBX014.nsn-intra.net> <0068A45E-559D-451A-B329-C23AD149D5F6@nostrum.com>
In-Reply-To: <0068A45E-559D-451A-B329-C23AD149D5F6@nostrum.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.159.42.108]
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: 2330
X-purgate-ID: 151667::1385570887-00006154-EBF47E17/0-0/0-0
Cc: "dime@ietf.org" <dime@ietf.org>
Subject: Re: [Dime] Ongoing Throttling Information in request messages
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, 27 Nov 2013 16:48:13 -0000

Ben,

Please see inline.

Ulrich

-----Original Message-----
From: ext Ben Campbell [mailto:ben@nostrum.com] 
Sent: Wednesday, November 27, 2013 4:30 PM
To: Wiehe, Ulrich (NSN - DE/Munich)
Cc: ext Nirav Salot (nsalot); dime@ietf.org
Subject: Re: [Dime] Ongoing Throttling Information in request messages


On Nov 27, 2013, at 5:21 AM, Wiehe, Ulrich (NSN - DE/Munich) <ulrich.wiehe@nsn.com> wrote:

> Ben,
> 
> thank you for not objecting to marking requests that survived a throttling.

To be clear, by "not objecting" I mean that I think it might be a worthwhile extension to pursue, but I'm not convinced it needs to go in the base spec.

> From here it is only a small step to additionally indicate which type of throttling (10% or 80% or.... identified by timestamp) the request survived.

I'm not sure what the purpose of that would be.
[Wiehe, Ulrich (NSN - DE/Munich)] This is to allow the reporting node to detect whether the reacting node is already doing the correct throttling or whether it is still doing a throttling based on stale information and therefore needs to be updated with the latest OLR.

> 
> Open issue is to assess whether
> 
> a) executing some logic (timestamp check) always + sending OLR only in the very few cases where it is needed
> is more expensive (in terms or resource consumption contributing to overload) than
> b) sending OLR always

Agreed, but with the caveat that we still have c) reporting node resends when it wants to.
[Wiehe, Ulrich (NSN - DE/Munich)] no. It's either "send OLR when needed and when not needed" (i.e. always see b)) or "send OLR when needed and don't send OLR when not needed (see a)). "do what you want" would allow not sending OLR although needed.

> 
> One approach could be to 
> - mandate sending of Ongoing-Throttling-Information(TimeStamp) in request messages by acting nodes while performing throttling
> - reporting nodes that are in overload may either do a) or b) whatever is regarded less resource consuming by the implementation
> - reporting nodes that are not (no longer) overloaded must do a)

Why the last point? I'd leave it as a MAY for both cases.
[Wiehe, Ulrich (NSN - DE/Munich)] because non-overloaded reporting nodes do not do b)

v2.23.0 | Report a Bug | By Email