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 11: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 E18501AE197 for <dime@ietfa.amsl.com>; Wed, 27 Nov 2013 03:23:44 -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 tOwrqUTO2Kjr for <dime@ietfa.amsl.com>; Wed, 27 Nov 2013 03:23:23 -0800 (PST)
Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 1E3C31AE25A for <dime@ietf.org>; Wed, 27 Nov 2013 03:21:14 -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 rARBLA8i016058 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 27 Nov 2013 12:21:10 +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 rARBLA2c024856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 27 Nov 2013 12:21:10 +0100
Received: from DEMUMBX014.nsn-intra.net ([169.254.14.152]) by DEMUHTC002.nsn-intra.net ([10.159.42.33]) with mapi id 14.03.0123.003; Wed, 27 Nov 2013 12:21:09 +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+wAADoRNAABgE0oAAA57DwAACoAlAAASWEQAAAqKUAACDdWeAAAz9GUAABLecQA88nH4AAHvcuwA==
Date: Wed, 27 Nov 2013 11:21:09 +0000
Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519B9C1@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> <DCB30089-EEA0-47C7-9FF5-0069A066966F@nostrum.com>
In-Reply-To: <DCB30089-EEA0-47C7-9FF5-0069A066966F@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: 1974
X-purgate-ID: 151667::1385551270-000022AE-E29BA9EC/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 11:23:45 -0000

Ben,

I disagree.

The requirement is not to "...determine _whether or not _ the overload condition improved or ended".
The word "when" has a strong reference to "point in time". 
The timeout mechanism does not allow the consumer of overload information to detect the point in time at which the overload condition ends.

Also: REQ 8 is not addressed by the timeout mechanism as overload information may become stale before expiry.

Ulrich
 


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


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

> Furthermore you seem not to take REQ 10 seriously. My understanding was that timeout is last resort, not the normal way.

I disagree with that conclusion.

Quoting RFC 7068:

> Consumers of overload information MUST be able to determine
>            when the overload condition improves or ends.



That text does not contemplate any particular mechanism, e.g. timeouts vs explicit notification. It merely requires that a mechanism exists.  The solution draft actually has _two_ mechanism for this (i.e. timeouts and explicit notification.) It's up to the implementation to figure out the exact details. Sure, it would be bad form for a node to declare an hour long overload period, have it resolve in a few seconds, and then leave the reacting nodes hanging for the rest of the hour.

 OTOH, I see nothing wrong at the protocol level with Nirav's case of having a short timeout, and just letting it expire. Whether it's the most efficient approach is another issue. We might offer guidance on that, but I would expect such guidance to be non-normative advice.

v2.23.0 | Report a Bug | By Email