[sip-overload] Proposal: Support for the restriction algorithms should be mandatory for clients (draft-ietf-soc-overload-control-02)

<phil.m.williams@bt.com> Thu, 28 April 2011 08:42 UTC

Return-Path: <phil.m.williams@bt.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 F3A60E06EA for <sip-overload@ietfa.amsl.com>; Thu, 28 Apr 2011 01:42:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.805
X-Spam-Level:
X-Spam-Status: No, score=-0.805 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, SARE_LWSHORTT=1.24]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hss+5zUe-8Y5 for <sip-overload@ietfa.amsl.com>; Thu, 28 Apr 2011 01:42:30 -0700 (PDT)
Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id 69EFAE06DD for <sip-overload@ietf.org>; Thu, 28 Apr 2011 01:42:29 -0700 (PDT)
Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 28 Apr 2011 09:42:28 +0100
Received: from EVMHT05-UKBR.domain1.systemhost.net (193.113.108.58) by EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) with Microsoft SMTP Server (TLS) id 8.3.106.1; Thu, 28 Apr 2011 09:42:28 +0100
Received: from EMV04-UKBR.domain1.systemhost.net ([169.254.1.221]) by EVMHT05-UKBR.domain1.systemhost.net ([193.113.108.58]) with mapi; Thu, 28 Apr 2011 09:42:28 +0100
From: phil.m.williams@bt.com
To: sip-overload@ietf.org
Date: Thu, 28 Apr 2011 09:42:17 +0100
Thread-Topic: Proposal: Support for the restriction algorithms should be mandatory for clients (draft-ietf-soc-overload-control-02)
Thread-Index: AcwFgC3R6VQLQZV2Q7+mAbReuc9w7A==
Message-ID: <E4B3F0DC6D953D4EBEC223BC86FE322C4A42034FB7@EMV04-UKBR.domain1.systemhost.net>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-cr-puzzleid: {50F5D2B8-BC25-4A1F-986C-C4BBA644DA19}
x-cr-hashedpuzzle: BLBx C7Vf DW7N DyLg Ej4u EuAV Fc+X GmKg HlrM IAh8 IPDt J1vl J7CP Kj9m K1NZ MHcC; 1; cwBpAHAALQBvAHYAZQByAGwAbwBhAGQAQABpAGUAdABmAC4AbwByAGcA; Sosha1_v1; 7; {50F5D2B8-BC25-4A1F-986C-C4BBA644DA19}; cABoAGkAbAAuAG0ALgB3AGkAbABsAGkAYQBtAHMAQABiAHQALgBjAG8AbQA=; Thu, 28 Apr 2011 08:42:17 GMT; UAByAG8AcABvAHMAYQBsADoAIABTAHUAcABwAG8AcgB0ACAAZgBvAHIAIAB0AGgAZQAgAHIAZQBzAHQAcgBpAGMAdABpAG8AbgAgAGEAbABnAG8AcgBpAHQAaABtAHMAIABzAGgAbwB1AGwAZAAgAGIAZQAgAG0AYQBuAGQAYQB0AG8AcgB5ACAAZgBvAHIAIABjAGwAaQBlAG4AdABzACAAKABkAHIAYQBmAHQALQBpAGUAdABmAC0AcwBvAGMALQBvAHYAZQByAGwAbwBhAGQALQBjAG8AbgB0AHIAbwBsAC0AMAAyACkA
acceptlanguage: en-US, en-GB
Content-Type: multipart/alternative; boundary="_000_E4B3F0DC6D953D4EBEC223BC86FE322C4A42034FB7EMV04UKBRdoma_"
MIME-Version: 1.0
Subject: [sip-overload] Proposal: Support for the restriction algorithms should be mandatory for clients (draft-ietf-soc-overload-control-02)
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: Thu, 28 Apr 2011 08:42:31 -0000

SIP support for 3 restriction algorithms at client sources defined in soc-overload-control-02 is beneficial for the flexibility that it provides to potentially support a wide range of server overload controls and network applications. However, making proportional restriction, termed a 'loss-based' algorithm, mandatory for clients would severely limit the usefulness of this approach.

I will summarise the reasons for this and why this algorithm has limited use in future generations of networks below.

Practical issues
-----------------------
If client system suppliers are only required to support proportional restriction, then realistically it is likely that that is the only algorithm that will be provided by default, and the other algorithms will be seen as chargeable enhancements, making it difficult or expensive to deploy them.

But, of the two functional ends of a closed adaptive overload control, it is the algorithm on the overloaded server that derives the control parameter that is not standardised and has dependency on node architecture, whereas the 3 client restriction algorithms are less subject to design variation, have been around for a long time, and are already widely deployed. Therefore we would expect it to be less contentious to standardise these methods within SIP, but in any case we would expect less sensitivity to design variations.

It is not realistic to envisage a situation whereby an overloaded server supports several different client restriction algorithms simultaneously, because of the complexity in design of the algorithm, and because even if a unique solution is guaranteed, there will be issues of both speed of convergence to that solution, stability, and the need for the server capacity amongst upstream clients to be allocated in a predictable and precise way. This has implications for capacity guarantees, particularly at network boundaries (see below).

If support for the 3 different restriction algorithms (or at least the 2 in which we are interested) is mandated by the IETF rather than being optional, then a server subject to overload can guarantee that the sending entities will all use the same restriction algorithms, and can behave as predicted.

Performance imitations
----------------------------------
The main performance limitation of proportional restriction is that it is vulnerable to sudden increases on the offered load at client sources, since the mean admitted rate after control is proportional to the mean arrival rate before control until an adaptation of the control parameter is made. But there will always be a delay to this control adaptation (at least in the closed loop method implied by the current specification), both because of the need for waiting sufficiently long at the overloaded server in order to obtain statistically accurate estimates before an adaptation is made, and the time and number of received messages required to distribute control to the clients. This vulnerability is worse when the number of clients is 'large' with a high capacity relative to the server. In contrast, a maximum rate-based control is generally not so vulnerable to short term surges in load.

The need to support precise capacity guarantees
------------------------------------------------------------------------
It is common practice for agreements concerning capacity to be provided at network operator boundaries [from now on I'll use SP or Service Provider as a generic term encompassing Operators etc], and in many realistic applications this is essential (I recall that his requirement is absent from the original list of SIP overload control requirements?). It is also possible to want to provide guarantees to sub-streams of SP traffic.

These guarantees must be practically useful, so that they can form the basis of a service level agreement between SPs. I.e. they must be simple enough to be easily understood by all parties, and above all they must be clear and precise in the sense that the behaviour of the capacity is predictable/deterministic (in a stochastic sense). SPs are not interested in technicalities of restriction algorithms, but will want the policies to be defined in terms of traffic characteristics that are straightforward to interpret and agree.

Clearly the policies must also be efficient in the sense that imply that the available capacity can be fully utilised. I suggest that these are most easily expressed as a guaranteed minimum rate and a precise way in which 'spare' capacity not being used by a client originated stream is distributed over the other SPs, e.g. in terms of maximum rates determined by agreed proportions of the available unused allowances. Of course other policies are possible (but they may be less precise or more complex). Whatever policies are chosen, realising this is an inherent part of the server overload control, but the difficulty and complexity is dependent upon the method of call restriction is the clients.

With proportional restriction, note that the percentages have nothing directly to do with the proportions of server capacity allocated to different clients. So there is no natural and simple way to map between the parameters of the agreement and the control parameters. If the same control level were applied to all client traffic, then the changes in the offered traffic from one client will always imply changes to the traffic admitted by another, (and in particular this applies to sudden large increases). To apply maximum rate-based guarantees would require monitoring of the received rate from each source separately in order that the offered traffic can be derived implicitly and thereby percentages derived for each specific source.

In contrast, with a rate-based restriction, it is much simpler to implement policies defined in terms of maximum rates, even though these are adapted according to minimum guarantees and use of unused allowances in a precise and predictable way.

Comments please!

Phil Williams