From phil.m.williams@bt.com Wed May 11 03:34:18 2011 Return-Path: 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 80489E0701 for ; Wed, 11 May 2011 03:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.794 X-Spam-Level: * X-Spam-Status: No, score=1.794 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_MISMATCH_COM=0.553, 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 qZzqEJ9wslQq for ; Wed, 11 May 2011 03:34:17 -0700 (PDT) Received: from smtpe1.intersmtp.com (smtp63.intersmtp.COM [62.239.224.236]) by ietfa.amsl.com (Postfix) with ESMTP id C7F3CE0720 for ; Wed, 11 May 2011 03:34:16 -0700 (PDT) Received: from EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) by RDW083A007ED63.smtp-e3.hygiene.service (10.187.98.12) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 11 May 2011 11:34:14 +0100 Received: from EVMHT05-UKBR.domain1.systemhost.net (193.113.108.58) by EVMHT63-UKRD.domain1.systemhost.net (10.36.3.100) with Microsoft SMTP Server (TLS) id 8.3.159.2; Wed, 11 May 2011 11:34:14 +0100 Received: from EMV04-UKBR.domain1.systemhost.net ([169.254.1.181]) by EVMHT05-UKBR.domain1.systemhost.net ([193.113.108.58]) with mapi; Wed, 11 May 2011 11:34:14 +0100 From: To: Date: Wed, 11 May 2011 11:34:08 +0100 Thread-Topic: [sip-overload] Proposal: Support for the restriction algorithms should be mandatory for clients (draft-ietf-soc-overload-control-02) Thread-Index: AcwGEgfMXeAsAOTdS3O+TCMuWeAiewJBjU+Q Message-ID: References: <4DBA1D11.7030001@alcatel-lucent.com> In-Reply-To: <4DBA1D11.7030001@alcatel-lucent.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sip-overload@ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2011 10:34:18 -0000 Thanks Volker, Apologies for the slow response (sent out just before I went on leave). I h= ave included some comments below. I'll look at the other responses... Regards, Phil Williams -----Original Message----- From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] = On Behalf Of Volker Hilt Sent: 29 April 2011 03:06 To: sip-overload@ietf.org Subject: Re: [sip-overload] Proposal: Support for the restriction algorithm= s should be mandatory for clients (draft-ietf-soc-overload-control-02) Phil, > 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. So you are arguing that a client should always implement the full set of=20 restriction algorithms (e.g., loss, rate and window)? [PhilW] Yes. I was arguing for all 3 so as to not favour any particular met= hod. However, I think that SLAs most naturally require a maximum rate-based= method, and for this purpose I don't really see the need to mandate window= -based methods. However, I others may have particular reasons for applying = a windowing method. If we would mandate that, we would loose the possibility to extend the=20 feedback types at a later point. [PhilW] I'm not sure why this is the case. Could you clarify? And, of course, we add the complexity=20 of requiring clients to implement multiple algorithms that to the same. [PhilW] Yes, there is an additional 'complexity', but as I pointed out thes= e methods are well known and have been deployed widely for a long time, so = I don't see this as being a significant issue. The fact that they would not= be available by default and have to be specifically required would be a mo= re serious factor, increasing costs and preventing or complicating their de= ployment. > 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. Can you please point us to results that show this behavior? [PhilW] This can be substantiated by theory, but note that there are many c= onditions that will affect the magnitude of this issue, which will depend u= pon the specific network application. The simulations that I did to investi= gate this were done over 15 years ago - I'm not sure that I can recover or = replicate these in my current situation. Note a particular critical issue f= or this scenario that applies to all algorithms (and can therefore adversel= y affect modelling results) is 'synchronisation' or 'resonance'. This occur= s when the instances of restriction algorithms at multiple sources are sync= hronised because they are using the same deterministic algorithm (e.g. 'm i= n n' rejected for proportional or synchronised bucket fill for rate-based).= This results in very peaky arrivals at the overloaded server (hence highly= variable throughput, long response time tails or lost messages, unstable c= ontrol) There are good and not so good ways to overcome this... I'd also recommend to look at the results of the SIP overload control=20 design team that has investigated this problem. [PhilW] I will do. > 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. A rate based mechanism needs to split its capacity across upstream=20 neighbors. If new clients arrive, the split has to be adjusted. In=20 particular if you are dealing with a large set of clients some of which=20 may be inactive for some time, this requires a quick readjustment of the=20 allocated capacity. This topic has been discussion in the design=20 considerations draft. [PhilW] Yes, but for this situation an adjustment of the control parameter = is required whatever restriction algorithm is used. In the case of proporti= onal loss this will be the % rejected, and all source streams will be affec= ted. A difference with a rate-based scheme is that once the leaky bucket is= full the upper rate is bounded, so therefore there is an upper bound on th= e aggregated admission rate over all sources before any control adaptation = takes place. Note also that where a stream is already under control by a re= strictor bucket with an admission rate at the max, then any increase in the= offered rate will not require any adjustment of control parameters. This i= sn't true for proportional rejection, since the admission rate is proportio= nal to the offered (arrival) rate at each source until an adaptation has be= en distributed. > 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. I don't think overload control is the right tool to police SLAs. [PhilW] An overload control always enforces a capacity allocation method, a= nd is therefore performing a policing function. This may be predictable, an= d either agreed between the owners of the traffic streams or not (and there= fore would not be regarded formally as an SLA), or unpredictable, e.g. for = badly designed overload control schemes, including the situation where the = solution in terms of allocation over sources is not unique so that stochast= ic convergence never occurs. Unfortunately at certain network locations the= absence of a predictable allocation can be unacceptable. Let's assume for a second you are in fact using overload control for=20 this purpose and are configuring your overload control rates to match=20 your SLAs. Say you have two servers A and B (each with capacity 500=20 req/s) and four upstream neighbors. The SLA with each of them is that=20 you accept 250 req/s. If one of your servers goes down, your capacity is cut in half. If you=20 have configured overload control to honor you SLAs, your remaining=20 server will melt down within ms. Your only choice to survive this=20 situation is to use overload control and cut the rates below the SLA. [PhilW] For this reason control (levels) at sources should always be specif= ic to an overloaded server, i.e. there should not be a single restrictive c= ontrol for multiple target servers. When load is distributed (balanced etc)= over more than one destination server the distribution function should the= refore always precede the restriction (overload) function, not the other wa= y around. So that in your example each source would have two independent re= strictive control associations, one with A and another with B. The load dis= tribution over these might be simple round-robin, so that if they are both = controlling at 125 req/s and say A fails, then the 125 req/sec to A would b= e rejected. There is no surge of traffic to B. Of course it is most likely = that the overload would arise only after the failure, but this requires opt= imum setting of control levels for initiation of control. (More generally o= ne can show that certain rate-based SLAs can be arranged to apply over a se= t of servers over which load is distributed, and that if the load is balanc= ed in the same proportions as the rates, then the policy is invariant to th= e number of working servers in the set, but this requires some theory). Thanks, Volker (as individual) > Comments please! > Phil Williams _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload From internet-drafts@ietf.org Wed May 18 14:45:15 2011 Return-Path: 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 6C0A1E0790; Wed, 18 May 2011 14:45:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.564 X-Spam-Level: X-Spam-Status: No, score=-102.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 ioyFPRW+CED5; Wed, 18 May 2011 14:45:14 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE725E0785; Wed, 18 May 2011 14:45:14 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.54 Message-ID: <20110518214514.22899.64038.idtracker@ietfa.amsl.com> Date: Wed, 18 May 2011 14:45:14 -0700 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-overload-design-06.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 21:45:15 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the SIP Overload Control Working Group of= the IETF. Title : Design Considerations for Session Initiation Protocol (S= IP) Overload Control Author(s) : Volker Hilt Eric Noel Charles Shen Ahmed Abdelal Filename : draft-ietf-soc-overload-design-06.txt Pages : 24 Date : 2011-05-18 Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document discusses models and design considerations for a SIP overload control mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-soc-overload-design-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-soc-overload-design-06.txt From volker.hilt@alcatel-lucent.com Wed May 18 14:53:26 2011 Return-Path: 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 2E271E07B5 for ; Wed, 18 May 2011 14:53:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vxPl8pZ6P3Xd for ; Wed, 18 May 2011 14:53:25 -0700 (PDT) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id A83B0E0794 for ; Wed, 18 May 2011 14:53:25 -0700 (PDT) Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p4ILrON1026442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 18 May 2011 16:53:24 -0500 (CDT) Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p4ILrM6H010682 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 18 May 2011 16:53:24 -0500 Received: from [135.112.131.41] (135.3.63.242) by USNAVSXCHHUB02.ndc.alcatel-lucent.com (135.3.39.111) with Microsoft SMTP Server (TLS) id 8.3.106.1; Wed, 18 May 2011 16:53:10 -0500 Message-ID: <4DD43FB3.2030807@alcatel-lucent.com> Date: Wed, 18 May 2011 17:52:51 -0400 From: Volker Hilt User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10 MIME-Version: 1.0 To: "sip-overload@ietf.org" Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10 Subject: [sip-overload] Fwd: New Version Notification - draft-ietf-soc-overload-design-06.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 May 2011 21:53:26 -0000 Folks, I've posted a new version of the design considerations draft: New version (-06) has been submitted for draft-ietf-soc-overload-design-06.txt. http://www.ietf.org/internet-drafts/draft-ietf-soc-overload-design-06.txt Diff from previous version: http://tools.ietf.org/rfcdiff?url2=draft-ietf-soc-overload-design-06 Thanks, Volker From iesg-secretary@ietf.org Tue May 31 11:44:08 2011 Return-Path: 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 455ECE07F2; Tue, 31 May 2011 11:44:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.467 X-Spam-Level: X-Spam-Status: No, score=-102.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, USER_IN_WHITELIST=-100] 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 X1alv8u6mZ+x; Tue, 31 May 2011 11:44:07 -0700 (PDT) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6D14E0780; Tue, 31 May 2011 11:44:07 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.55 Message-ID: <20110531184407.453.55068.idtracker@ietfa.amsl.com> Date: Tue, 31 May 2011 11:44:07 -0700 Cc: sip-overload@ietf.org Subject: [sip-overload] Last Call: (Design Considerations for Session Initiation Protocol (SIP) Overload Control) to Informational RFC X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: ietf@ietf.org List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 31 May 2011 18:44:08 -0000 The IESG has received a request from the SIP Overload Control WG (soc) to consider the following document: - 'Design Considerations for Session Initiation Protocol (SIP) Overload Control' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-06-14. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document discusses models and design considerations for a SIP overload control mechanism. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-soc-overload-design/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-soc-overload-design/ No IPR declarations have been submitted directly on this I-D.