Re: [sip-overload] Enhancement to Load Control Event Package to support partial updates to control restriction parameters and validity

"SHEN, CHARLES" <cs4303@att.com> Mon, 07 November 2011 20:07 UTC

Return-Path: <cs4303@att.com>
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD33A11E80B4 for <sip-overload@ietfa.amsl.com>; Mon, 7 Nov 2011 12:07:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NRdsvfOLRZtg for <sip-overload@ietfa.amsl.com>; Mon, 7 Nov 2011 12:07:31 -0800 (PST)
Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by ietfa.amsl.com (Postfix) with ESMTP id 6F72F11E80B0 for <sip-overload@ietf.org>; Mon, 7 Nov 2011 12:07:31 -0800 (PST)
X-Env-Sender: cs4303@att.com
X-Msg-Ref: server-10.tower-120.messagelabs.com!1320696449!48091549!1
X-Originating-IP: [144.160.20.145]
X-StarScan-Version: 6.3.6; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 24029 invoked from network); 7 Nov 2011 20:07:29 -0000
Received: from sbcsmtp6.sbc.com (HELO mlpd192.enaf.sfdc.sbc.com) (144.160.20.145) by server-10.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Nov 2011 20:07:29 -0000
Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA7K7tJQ000829; Mon, 7 Nov 2011 15:07:56 -0500
Received: from MISOUT7MSGHUB9C.ITServices.sbc.com (misout7msghub9c.itservices.sbc.com [144.151.223.82]) by mlpd192.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id pA7K7bcI032669 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 7 Nov 2011 15:07:51 -0500
Received: from MISOUT7MSGUSR9A.ITServices.sbc.com ([169.254.1.121]) by MISOUT7MSGHUB9C.ITServices.sbc.com ([144.151.223.82]) with mapi id 14.01.0339.001; Mon, 7 Nov 2011 15:07:12 -0500
From: "SHEN, CHARLES" <cs4303@att.com>
To: "sip-overload@ietf.org" <sip-overload@ietf.org>
Thread-Topic: [sip-overload] Enhancement to Load Control Event Package to support partial updates to control restriction parameters and validity
Thread-Index: Acxhq768aXwRR+/ZR8icaOn+l4FJjQ73KJqQ
Date: Mon, 7 Nov 2011 20:07:12 +0000
Message-ID: <9EC99DA9F107DF4A8AD7B332FB5FC5CD01628134@MISOUT7MSGUSR9A.ITServices.sbc.com>
References: <E4B3F0DC6D953D4EBEC223BC86FE322C4A5C57E13C@EMV04-UKBR.domain1.systemhost.net>
In-Reply-To: <E4B3F0DC6D953D4EBEC223BC86FE322C4A5C57E13C@EMV04-UKBR.domain1.systemhost.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [151.109.8.243]
Content-Type: multipart/alternative; boundary="_000_9EC99DA9F107DF4A8AD7B332FB5FC5CD01628134MISOUT7MSGUSR9A_"
MIME-Version: 1.0
Subject: Re: [sip-overload] Enhancement to Load Control Event Package to support partial updates to control restriction parameters and validity
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload <sip-overload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-overload>
List-Post: <mailto:sip-overload@ietf.org>
List-Help: <mailto:sip-overload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Nov 2011 20:07:34 -0000

Hi all: I am in the process of producing an updated version of the "Load Control Event Package" document. I would like to seek the group's opinion on the following proposal from Phil earlier.

Thanks

Charles

From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of phil.m.williams@bt.com
Sent: Tuesday, August 23, 2011 11:46 AM
To: sip-overload@ietf.org
Subject: [sip-overload] Enhancement to Load Control Event Package to support partial updates to control restriction parameters and validity

Folks,

I have proposed to the authors of draft-ietf-soc-load-control-event-package-01 that Notifications of partial updates to control restriction parameters and validity (only) should be supported. Currently the spec explicitly states that they are not, in 5.7.(Notifier Generation of NOTIFY Requests):

...This event package does not support notifications that contain deltas to previous information or partial information.

This proposal is fine with Charles Shen, so we agreed to open it up for general views. My reasoning follows.

It would be common practice for updates to specific load control events to be made frequently by changing the control restriction parameter information only (e.g. rate, percent), but not other rule elements, such as call-identity. This will typically be because the utilisation of a resource subject to overload depends upon dynamic unknowns such as holding time and the relative distribution of offered load over subscribing SIP entities. The updates could originate manually or be determined automatically. The latter is referred to already in 4.2.(Filter Computation):

...it may be preferable to employ a dynamic load computation algorithm which adapts to current network status, rather than using a purely static mechanism.  The filter content computation algorithm is out of scope of this document.

[Note: A rate-based control would generally need a lower frequency of updates even when adaptive than say a loss-based method because of the dependence of the proportional method upon offered rates].

Another factor usually not known precisely or computed automatically is the duration of the load control event. Therefore it would also be common for the validity to change frequently.

Not allowing partial updates could be a significant limitation to performance when realised, since it makes such updates unnecessarily verbose. It would be a small enhancement to allow deltas which change the rate, win, or percent values of the action element, and the validity. They can be associated to the complete rule through the rule id.

Regards,

Phil Williams