Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

"Nirav Salot (nsalot)" <nsalot@cisco.com> Thu, 06 February 2014 15:49 UTC

Return-Path: <nsalot@cisco.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 5BA331A01B1 for <dime@ietfa.amsl.com>; Thu, 6 Feb 2014 07:49:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.036
X-Spam-Level:
X-Spam-Status: No, score=-10.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.535, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.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 ZkoTUzM5EmTB for <dime@ietfa.amsl.com>; Thu, 6 Feb 2014 07:49:09 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5DAAC1A01E1 for <dime@ietf.org>; Thu, 6 Feb 2014 07:49:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16172; q=dns/txt; s=iport; t=1391701748; x=1392911348; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=74LkHPc8ZZjhEPsiqfWVBDgnTnweKtwK3tl4YYCYQY4=; b=OXWiVoofm8UaL7i7yMgnnOMcWXDYKOBGdxSCHOUIYqbYrci/lihohEas Zw6P86mD8n4UbEOy8D/X+ZLTLZE4u40EMworIzIdUxom/P/shYvqCBNfa bxU4EzpyrfE966NJRRLcqKa7+ql11/tgdfAslhGVQz79MjzS0YUeWY7+G o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgcFAESu81KtJXG9/2dsb2JhbABZgww4V4MBu3AYcxZ0giUBAQEEAQEBIBE6FwQCAQgRBAEBAwIGGQQDAgICJQsUAQgIAgQBEgiHfQ2sfaEiEwSBKYxvEQEfFiIGgmk1gRQElEKORodEgW+BPoFxOQ
X-IronPort-AV: E=Sophos;i="4.95,793,1384300800"; d="scan'208";a="18473410"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by alln-iport-6.cisco.com with ESMTP; 06 Feb 2014 15:49:07 +0000
Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id s16Fn7s6007578 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 6 Feb 2014 15:49:07 GMT
Received: from xmb-rcd-x10.cisco.com ([169.254.15.55]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0123.003; Thu, 6 Feb 2014 09:49:07 -0600
From: "Nirav Salot (nsalot)" <nsalot@cisco.com>
To: "Wiehe, Ulrich (NSN - DE/Munich)" <ulrich.wiehe@nsn.com>, "ext lionel.morand@orange.com" <lionel.morand@orange.com>, ext Steve Donovan <srdonovan@usdonovans.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
Thread-Index: AQHPIb778GZL0FnWy0+sBFi5Rl7mNpqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7Kfw
Date: Thu, 06 Feb 2014 15:49:06 +0000
Message-ID: <A9CA33BB78081F478946E4F34BF9AAA014D65226@xmb-rcd-x10.cisco.com>
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <25535_1391528227_52F10923_25535_243_1_6B7134B31289DC4FAF731D844122B36E4771BD@PEXCVZYM13.corporate.adroot.infra.ftgroup> <A9CA33BB78081F478946E4F34BF9AAA014D62A2A@xmb-rcd-x10.cisco.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B2153@DEMUMBX014.nsn-intra.net> <52F24ACE.6080501@usdonovans.com> <A9CA33BB78081F478946E4F34BF9AAA014D6432A@xmb-rcd-x10.cisco.com> <52F25A38.2030408@usdonovans.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B22FB@DEMUMBX014.nsn-intra.net> <A9CA33BB78081F478946E4F34BF9AAA014D64E69@xmb-rcd-x10.cisco.com> <29031_1391678397_52F353BD_29031_478_2_6B7134B31289DC4FAF731D844122B36E48CA45@PEXCVZYM13.corporate.adroot.infra.ftgroup> <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>
In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151B233F@DEMUMBX014.nsn-intra.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.108.45.36]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
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: Thu, 06 Feb 2014 15:49:12 -0000

Ulrich,

It seems we all are on same page but probably the proposed wording below is not the best.
How about the following.

When the reporting node wants to provide new overload report or wants to update the earlier provided overload report towards a reacting node, it shall include OLR in the response, to the request containing OC-Supported-Feature AVP, towards the corresponding reacting node. Additionally, in other cases, e.g. when the reporting node is not aware if the overload report is already provided to the reacting node, the reporting node may include the OLR in the response, to the request containing OC-Supported-Feature AVP.

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
Sent: Thursday, February 06, 2014 3:57 PM
To: ext lionel.morand@orange.com; Nirav Salot (nsalot); ext Steve Donovan; dime@ietf.org
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Nirav, Lionel,

I can understand Nirav's concern (although violating REQ10) and hop it is addressed by the modified principle 2':

2'. the reporting node (no matter whether overloaded or not) MAY decide not to return an OLR in response to requests which contained an OC-Supported-Feature AVP if it is aware that the reacting node already has got reasonable overload control information (e.g. the latest OLR, which may be an OLR requesting traffic reduction or an OLR indicating "no overload", or an old  but soon expiring OLR when the reporting node is not overloaded); otherwise (i.e. if it is not aware...) the reporting node (no matter whether overloaded or not) MUST return an OLR in responses to requests which contained an OC-Supported-Feature AVP.

I don't agree with Lionels do-what-you-want approach. Overload control will not work when we allow the reporting node not to update reacting nodes, which are not (sufficiantly) aware of the current overload status, with up to date OLRs.

Ulrich  



-----Original Message-----
From: ext lionel.morand@orange.com [mailto:lionel.morand@orange.com] 
Sent: Thursday, February 06, 2014 10:20 AM
To: Nirav Salot (nsalot); Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling



-----Message d'origine-----
De : DiME [mailto:dime-bounces@ietf.org] De la part de Nirav Salot (nsalot)
Envoyé : jeudi 6 février 2014 10:08
À : Wiehe, Ulrich (NSN - DE/Munich); ext Steve Donovan; dime@ietf.org
Objet : Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Ulrich,

I am not sure about forcing this behavior on reporting node "otherwise (i.e. if it is not aware...) the reporting node (no matter whether overloaded or not) MUST return an OLR in responses to requests which contained an OC-Supported-Feature AVP."
The reporting node may simply not include OLR assuming that the earlier provided OLR will expire and the reacting node will stop throttling the traffic.

[LM] Agree. In other words, it is not deemed required for the default mechanism described in this draft. How and when the reporting node decides to include the OLR in the answer may depend on the application or on the implementation. At least, it is my current understanding.

As we had discussed earlier, there is no need for the reporting node to explicitly stop throttling at each reacting node at the same time. In other words, the reporting node can allow the natural expiry of the OLR to facilitate slow ramp of the signaling traffic towards it.

[LM] Agree

There may be other cases, e.g. when the reporting node knows that the last overload situation ended long time back in the past, there is no need for it to include OLR if currently there is no overload condition.

[LM] Agree

Rest of the principles below are fine with me.

[LM] Agree

Regards,
Nirav.

-----Original Message-----
From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] 
Sent: Thursday, February 06, 2014 2:23 PM
To: ext Steve Donovan; Nirav Salot (nsalot); dime@ietf.org
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Actually we seem to agree on two principles:
1. Lack of OLR means "no change"
2. the reporting node (no matter whether overloaded or not) MAY decide not to return an OLR in response to requests which contained an OC-Supported-Feature AVP if it is aware that the reacting node already has got the latest OLR (which may be an OLR requesting traffic reduction or an OLR indicating "no overload"); otherwise (i.e. if it is not aware...) the reporting node (no matter whether overloaded or not) MUST return an OLR in responses to requests which contained an OC-Supported-Feature AVP.

Can people please confirm.

Ulrich

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Steve Donovan
Sent: Wednesday, February 05, 2014 4:35 PM
To: Nirav Salot (nsalot); dime@ietf.org
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Agreed.  To restate -- lack of an overload report does not change the current overload state for the host or realm.  If there is a currently active overload report then it continues to apply until it either times out or is explicitly changed with a new overload report.  If there is no currently active overload report then lack of an overload report implies there is no overload for the host and realm.

Steve
On 2/5/14 9:19 AM, Nirav Salot (nsalot) wrote:
I agree with Steve except the part "shouldn’t lack of OLR be interpreted as not overloaded?"
 
We had some discussion sometime back and thought that it is reasonable to not mandate the server to include the OLR in every answer message. E.g. when the server is capable of tracking what is sent to which client and hence wants to avoid sending information which is redundant. But this is optional implementation and at the same time need not be prohibited from protocol point of view.
 
So basically, the lack of OLR should not affect the previously received OLR at the reacting node. The reacting node can continue to react based on older OLR until the expiry of the validity-period or when the explicit OLR with "0" overload-metric is received.
In my view, this allows for flexible implementation at the reporting node and sound handling of OLR at the reacting node.
 
Regards,
Nirav.
 
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Steve Donovan
Sent: Wednesday, February 05, 2014 8:00 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
 
inline
On 2/5/14 7:57 AM, Wiehe, Ulrich (NSN - DE/Munich) wrote:
Ok then let's state that reporting nodes MUST insert an OC-OLR AVP in all answer messages that correspond to request messages which contain an OC-Supported-Features AVP (even when no load reduction is requested).
SRD> Why in every answer message?  Shouldn't lack of an OLR be interpreted as not overloaded?


 
 
Other criteria like REQ18 or REQ13 do not seem to matter.
SRD> Requiring an overload report in every answer does directly break REQ13, but requiring an overloaded node to look for an OC-Ongoing-Throttling-Info AVP in every message is also substantial additional work, potentially more expensive than inserting OLRs.


 
 
For my clarification: I guess that the reacting node is not required to process every single OLR received (most will be replays anyway). What would be the procedure in the reacting node in order to minimize processing of replayed OLRs and at the same time minimize the risk too miss a new OLR?
SRD> That is the purpose of the sequence number.  


 
 
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of ext Nirav Salot (nsalot)
Sent: Wednesday, February 05, 2014 5:27 AM
To: lionel.morand@orange.com; dime@ietf.org
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
 
I share the same opinion as Lionel.
 
Regards,
Nirav.
 
-----Original Message-----
From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of lionel.morand@orange.com
Sent: Tuesday, February 04, 2014 9:07 PM
To: dime@ietf.org
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
 
I understand that the real concern is when the reporting node DOES NOT insert the OLR in every answer. 
So the options would be:
1- OC-OLR AVP in every answer
2- OC-Ongoing-Throttling-Info AVP in every request + OC-OLR AVP in some answer when the current throttling performed by the client needs to be updated.
 
If there is no other criterion, the option 1 seems the best approach.
 
Lionel
 
-----Message d'origine-----
De : dime issue tracker [mailto:trac+dime@trac.tools.ietf.org]
Envoyé : mardi 4 février 2014 09:49
À : MORAND Lionel IMT/OLN
Cc : dime@ietf.org
Objet : [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
 
#31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling
 
 It has been proposed to define an OC-Ongoing-Throttling-Info AVP that is  to be included by the reacting DOIC endpoint in request messages that  survived a throttling. This AVP would indicate the Sequence-Number
 (TimeStamp) of the OLR according to which the throttling (which was
 survived) is performed. Absence of this AVP indicates that currently no  throttling is performed.  Reporting DOIC endpoints may use this  information in order to detect whether there is a need to update the  reacting DOIC endpoint with the latest OLR.
 Absence of this feedback mechanism would result in the need for the  reporting node to send OC-OLR AVPs in every answer as the reporting DOIC  endpoint cannot know whether the reacting DOIC endpoint is actually doing  the right thing with regard to throttling/not throttling.
 The feedback mechanism improves robustness as it allows the reporting DOIC  endpoint to detect and correct inappropriate throttling by the reacting  DOIC endpoint (caused by whatever reason).
 The feedback mechanism also allows to address REQ 18 from RFC 7068.
 In summary it is proposed to define the OC-Ongoing-Throttling-Info AVP to  be used in request messages that survived a throttling.
 
 

_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.