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

Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com> Thu, 13 February 2014 15:07 UTC

Return-Path: <maria.cruz.bartolome@ericsson.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 8354D1A0209 for <dime@ietfa.amsl.com>; Thu, 13 Feb 2014 07:07:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 I47Z4_-sLxSt for <dime@ietfa.amsl.com>; Thu, 13 Feb 2014 07:07:38 -0800 (PST)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2EEDE1A02BC for <dime@ietf.org>; Thu, 13 Feb 2014 07:07:35 -0800 (PST)
X-AuditID: c1b4fb38-b7f418e000001099-5d-52fcdfb55774
Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 25.92.04249.5BFDCF25; Thu, 13 Feb 2014 16:07:33 +0100 (CET)
Received: from ESESSMB101.ericsson.se ([169.254.1.172]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0387.000; Thu, 13 Feb 2014 16:07:32 +0100
From: Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>
To: "Nirav Salot (nsalot)" <nsalot@cisco.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: AQHPIb76C0BpPfw8fUGGx+o9rHi8sJqmEXfQgAED7ACAAAkVAP//p7bggABqqgCAASHxgP//nLwwgAAFFKCAAHhxgP//7KfwADO95YAAC3A6AAB8+qLQAA2HuoAADH2UwP//obQAgABsT4CAAAY6AP//Pffg//56tTCAAvrqAP//7qjwAAKFcAAABx+bAAADVm4A//7JkxD//AYzsP/31vKA/++X+ND/3y9MUP++VEyA/3yVOgA=
Date: Thu, 13 Feb 2014 15:07:32 +0000
Message-ID: <087A34937E64E74E848732CFF8354B9209774E01@ESESSMB101.ericsson.se>
References: <066.5325af1f957cc4cc9501e6dda0b50a85@trac.tools.ietf.org> <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> <A9CA33BB78081F478946E4F34BF9AAA014D65226@xmb-rcd-x10.cisco.com> <5BCBA1FC2B7F0B4C9D935572D9000668151B24BA@DEMUMBX014.nsn-intra.net> <087A34937E64E74E848732CFF8354B9209772389@ESESSMB101.ericsson.se> <A9CA33BB78081F478946E4F34BF9AAA014D68B44@xmb-rcd-x10.cisco.com> <087A34937E64E74E848732CFF8354B92097726C5@ESESSMB101.ericsson.se> <A9CA33BB78081F478946E4F34BF9AAA014D68C65@xmb-rcd-x10.cisco.com> <087A34937E64E74E848732CFF8354B9209772718@ESESSMB101.ericsson.se> <52F8FC53.4070508@usdonovans.com> <8685_1392050573_52F9018D_8685_14082_1_6B7134B31289DC4FAF731D844122B36E497B0A@PEXCVZYM13.corporate.adroot.infra.ftgroup> <A9CA33BB78081F478946E4F34BF9AAA014D6978A@xmb-rcd-x10.cisco.com> <087A34937E64E74E848732CFF8354B9209772E88@ESESSMB101.ericsson.se> <A9CA33BB78081F478946E4F34BF9AAA014D697CA@xmb-rcd-x10.cisco.com> <087A34937E64E74E848732CFF8354B9209772EB3@ESESSMB101.ericsson.se> <4993_1392114947_52F9FD03_4993_223_1_6B7134B31289DC4FAF731D844122B36E499B60@PEXCVZYM13.corporate.adroot.infra.ftgroup> <087A34937E64E74E848732CFF8354B920977300C@ESESSMB101.ericsson.se> <10989_1392132919_52FA4337_10989_2146_1_6B7134B31289DC4FAF731D844122B36E49A34E@PEXCVZYM13.corporate.adroot.infra.ftgroup> <E194C2E18676714DACA9C3A2516265D2026645F9@FR712WXCHMBA11.zeu.alcatel-lucent.com> <087A34937E64E74E848732CFF8354B9209774836@ESESSMB101.ericsson.se> <A9CA33BB78081F478946E4F34BF9AAA014D6D626@xmb-rcd-x10.cisco.com> <087A34937E64E74E848732CFF8354B9209774C5E@ESESSMB101.ericsson.se> <A9CA33BB78081F478946E4F34BF9AAA014D6D6FF@xmb-rcd-x10.cisco.com>
In-Reply-To: <A9CA33BB78081F478946E4F34BF9AAA014D6D6FF@xmb-rcd-x10.cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.154]
Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209774E01ESESSMB101erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrBLMWRmVeSWpSXmKPExsUyM+Jvje7W+3+CDNqnSFnM7V3BZvFsVYoD k8eU3xtZPZYs+ckUwBTFZZOSmpNZllqkb5fAldF9YyJbwaFGpoo7L44xNTA++MXYxcjJISFg IjH1xixWCFtM4sK99WxdjFwcQgJHGCWW7b/HDuEsYZSYPfEHM0gVm4CdxKXTL5hAbBEBP4l5 PzaDdQsLlEu8vHSFGSJeIfF56yWomiYmib2/bEFsFgFVicYpp8DivAK+Em/7rjFCLNgnIHFh yT6gZg4OTqDEm2ZHkBpGoIu+n1oDVs8sIC5x68l8JohLBSSW7DnPDGGLSrx8/A/qAyWJRbc/ M4GMYRbIl9jf7QGxSlDi5MwnLBMYRWYhmTQLoWoWkiqIsKbE+l36ENWKElO6H7JD2BoSrXPm siOLL2BkX8XIUZxanJSbbmSwiREYOwe3/LbYwXj5r80hRmkOFiVx3o9vnYOEBNITS1KzU1ML Uovii0pzUosPMTJxcEo1MM4y88pQWc54z26ySoTX7bwO3yVbM1zdYg5c2jFpY5FyeDSn6ttJ 7AcerXvQs9B0udFE5wKrE0V7OhcVHJFnDL+SZMMt3dJ8dnl9/iyPmTZ7mFfpnZyUIKXYumL+ sVMzks5OvziZV7x8o4CjDWtlTIujuKaw3gzXKSUXEvYm2/I6SGixelx1VGIpzkg01GIuKk4E AL33IgBrAgAA
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, 13 Feb 2014 15:07:42 -0000

Nirav,

Let me know if following rephrasing still conveys the meaning you want to cover:

Note – In some cases (e.g. when there are one or multiple agents in the path between reporting and reacting nodes, or when overload reports are discarded by reacting nodes) the reporting node may not be able to guarantee that the reacting node has received the report.


From: Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
Sent: jueves, 13 de febrero de 2014 15:56
To: Maria Cruz Bartolome; dime@ietf.org
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Maria-Cruz,

May be following formatting of the note helps?
A reporting node MAY choose to not send an overload report to a reacting node if it can guarantee that this overload report is already active in the reacting node.

Note – In some cases (e.g. when there are one or multiple agents in the path between reporting and reacting nodes, overload reports may be discarded by reacting nodes) the reporting node may not be able to guarantee that the reacting node has received the report.

Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Thursday, February 13, 2014 6:50 PM
To: dime@ietf.org<mailto:dime@ietf.org>
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Nirav,

Do you consider that overload reports can only be discarded by reacting nodes when there are agents in the path?


From: Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
Sent: jueves, 13 de febrero de 2014 13:58
To: Maria Cruz Bartolome; dime@ietf.org<mailto:dime@ietf.org>
Subject: RE: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Maria-Cruz,

Reporting note may use very simple mechanism – as pointed out by Lionel – to conclude that report has reached the reacting node, i.e. all the intra-session messages need not contain the same overload report, if the session establishment message contains the overload report.

So your note regarding the reporting node to take into account the network deployment etc. is not 100% correct.
Let me simplify, hoping it will satisfy your concern.

A reporting node MAY choose to not send an overload report to a reacting node if it can guarantee that this overload report is already active in the reacting node.

Note – In some cases, e.g. when there are one or multiple agents in the path between reporting and reacting nodes; overload reports may be discarded by reacting nodes, the reporting node may not be able to guarantee that the reacting node has received the report.

Regards,
Nirav.

From: DiME [mailto:dime-bounces@ietf.org] On Behalf Of Maria Cruz Bartolome
Sent: Thursday, February 13, 2014 2:31 PM
To: dime@ietf.org<mailto:dime@ietf.org>
Subject: Re: [Dime] [dime] #31: Sending OC-Ongoing-Throttling-Info AVP in request messages that survived a throttling

Dear all,

I think then we agree on the proposed text:

A reporting node MUST ensure that all reacting nodes receive new overload reports.

It is recommended that a reporting node include overload reports in all answer messages sent to reacting nodes.

Note - the reporting node may also include the overload report in answer messages sent to non reacting nodes if that is more efficient.  The overload report will just be ignored by a Diameter node that does not support DOIC.

A reporting node MAY choose to not send an overload report to a reacting node if it can guarantee that the reacting node already has received the overload report.

But still there are some discrepancies about the note.
My proposal is to keep it just as an indication of potential (maybe not all) situations that should be taken into account if ever any implementation may consider to do not follow the recommendation that a reporting node include overload reports in all answer messages.
Being a recommendation and not a must, at least I think we need to indicate what may imply to do not follow the recommendation.
Then my proposal is the following, that includes a modification to last sentence above:

A reporting node MAY choose to not send an overload report to a reacting node if it can guarantee that this overload report is already active in the reacting node.

Note –the reporting node may need to take into account network deployment and potential errors in order to be able to guarantee that sent overload report is active in the reacting node, e.g. there may be one or multiple agents in the path between reporting and reacting nodes; overload reports may be discarded by reacting nodes…