Re: [Dime] OLR applicable for any/all applications

"Shishufeng (Susan)" <susan.shishufeng@huawei.com> Mon, 09 December 2013 10:52 UTC

Return-Path: <susan.shishufeng@huawei.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 5E6681AD8F2 for <dime@ietfa.amsl.com>; Mon, 9 Dec 2013 02:52:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-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 kQ0zkDyrcHUA for <dime@ietfa.amsl.com>; Mon, 9 Dec 2013 02:52:54 -0800 (PST)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 6947A1AE272 for <dime@ietf.org>; Mon, 9 Dec 2013 02:52:52 -0800 (PST)
Received: from 172.18.7.190 (EHLO lhreml203-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BBD96696; Mon, 09 Dec 2013 10:52:46 +0000 (GMT)
Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml203-edg.huawei.com (172.18.7.221) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 10:52:25 +0000
Received: from SZXEMA405-HUB.china.huawei.com (10.82.72.37) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 9 Dec 2013 10:52:29 +0000
Received: from SZXEMA512-MBX.china.huawei.com ([169.254.7.155]) by SZXEMA405-HUB.china.huawei.com ([10.82.72.37]) with mapi id 14.03.0158.001; Mon, 9 Dec 2013 18:52:18 +0800
From: "Shishufeng (Susan)" <susan.shishufeng@huawei.com>
To: Maria Cruz Bartolome <maria.cruz.bartolome@ericsson.com>, "dime@ietf.org" <dime@ietf.org>
Thread-Topic: [Dime] OLR applicable for any/all applications
Thread-Index: AQHO8AhKXZeJPtoJpkKNcVZUfn/T85pLuGcg
Date: Mon, 09 Dec 2013 10:52:17 +0000
Message-ID: <26C84DFD55BC3040A45BF70926E55F2587C1D0F1@SZXEMA512-MBX.china.huawei.com>
References: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se>
In-Reply-To: <087A34937E64E74E848732CFF8354B920972BE0C@ESESSMB101.ericsson.se>
Accept-Language: en-GB, zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.146.62.57]
Content-Type: multipart/alternative; boundary="_000_26C84DFD55BC3040A45BF70926E55F2587C1D0F1SZXEMA512MBXchi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Subject: Re: [Dime] OLR applicable for any/all applications
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: Mon, 09 Dec 2013 10:52:57 -0000

Hi MCruz,

I don't see any use case at least in 3GPP for this. There is no more than one application between two nodes so far. And even the case is valid, it could be reached by multiple sending of the overload report per application, which could be seen as an optimization in the future if there is clear scenario for such an optimization.

Best Regards,
Susan

From: Maria Cruz Bartolome [mailto:maria.cruz.bartolome@ericsson.com]
Sent: Tuesday, December 03, 2013 4:43 PM
To: dime@ietf.org
Subject: [Dime] OLR applicable for any/all applications


Dear all,

There may be a need by a reporting node to request traffic reduction for all traffic, application independent, e.g. if an operator's network becomes severely overloaded, it may be of interest to signal directly general overload to the client.
In this case, since reacting node obtains affected application from the application message, we may need to extend OLR.

At least we got following options:



A)     Define a new optional AVP that could be included into OLR, like e.g.:

   OC-OLR ::= < AVP Header: TBD2 >

              < TimeStamp >

              [ Reduction-Percentage ]

              [ ValidityDuration ]

              [ ReportType ]

              [All applications]

            * [ AVP ]



B)      Extend  ReportTypes like e.g.:

   3  Destination-Host All Applications report.  Similar to Destination-Host report but it would apply to any application regardless the application message this report is received within.

   4  Realm (aggregated) All Applications report.  Similar to Realm report but it would apply to any application regardless the application message this report is received within.



I tend to prefer option A, but let me know your opinions and preferences.
Best regards
/MCruz