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

"Bharrat, Shaun" <SBharrat@sonusnet.com> Fri, 29 April 2011 14:09 UTC

Return-Path: <SBharrat@sonusnet.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 1665DE074D for <sip-overload@ietfa.amsl.com>; Fri, 29 Apr 2011 07:09:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.359
X-Spam-Level:
X-Spam-Status: No, score=-1.359 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 3RMKZHQQoKVb for <sip-overload@ietfa.amsl.com>; Fri, 29 Apr 2011 07:09:51 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id 3C4D9E075B for <sip-overload@ietf.org>; Fri, 29 Apr 2011 07:09:49 -0700 (PDT)
Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p3TE9xU9024239; Fri, 29 Apr 2011 10:09:59 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Fri, 29 Apr 2011 10:07:31 -0400
Message-ID: <637C77B6763BB54ABF989B6B21D53235045F8DB2@sonusmail05.sonusnet.com>
In-Reply-To: <2F8FB48C17221643AD77FA295756D2A71E23562CF2@njfpsrvexg6.research.att.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [sip-overload] Proposal: Support for the restriction algorithms should be mandatory for clients (draft-ietf-soc-overload-control-02)
Thread-Index: AcwGEjm3TMkzlAWkQzeVk25eMD75YAAV2YmgAAG7yWA=
References: <E4B3F0DC6D953D4EBEC223BC86FE322C4A42034FB7@EMV04-UKBR.domain1.systemhost.net><4DBA1D11.7030001@alcatel-lucent.com> <2F8FB48C17221643AD77FA295756D2A71E23562CF2@njfpsrvexg6.research.att.com>
From: "Bharrat, Shaun" <SBharrat@sonusnet.com>
To: "NOEL, ERIC C (ERIC C)" <ecnoel@research.att.com>, "Volker Hilt" <volker.hilt@alcatel-lucent.com>, <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 <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: Fri, 29 Apr 2011 14:09:56 -0000

> In that paper, Figure 3 compares rate control to call gapping and to
> percent blocking. As offered load increases, rate control is the only
> algorithm that controls load close to the target. Basically Phil's
> point.

All:

As a VOIP gateway/SBC vendor in some large networks, we have seen this
effect. For the cases I have been involved in, it has happened when 
the network design has nodes arranged not is a strict hierarchy but
rather in a mesh where there are multiple paths between any two
particular
nodes and the paths are of different lengths. (As a degenerate case,
assume both A->C, and A->B->C). 

For these cases, we needed to implement rate (versus loss) control (at B

in the example) since the input load at B towards C could dramatically 
increase when A notices the distress at C for the direct A->C calls. 
(The load at B towards A can increase for a lot of reasons but this one
happens coincident with trying to control load towards C.)

That said, it wasn't feasible to implement rate control advertisements
from C. That possibility was amply discussed in the draft and on this
email list and we agree with the conclusions. Another concern is the 
addition of any complexity to the processing at C in order to track and
distribute rates per source... after all, this is the *overloaded* box.

In the end, what appears to work better (details are different but the
concept
is roughly right) is that the downstream (overloaded) node reports a
simple desired loss percentage, and the upstream uses that to *compute*
a rate towards the overloaded peer (100 -loss percentage)*(previous rate
towards that peer). In effect, the upstream node limits itself to the
loss percentage applied to the rate that produced that loss percentage.

Whether this is "allowed" by the overload draft was discussed last on
7/19/2010
	> -----Original Message-----
	> From: Volker Hilt [mailto:volker.hilt@alcatel-lucent.com]
	> Sent: Monday, July 19, 2010 5:48 AM
	> To: Bharrat, Shaun
	> Cc: sip-overload@ietf.org
	> Subject: Re: [sip-overload] SIP overload control draft -
sender
	> behavior

but it appears there wasn't a conclusion to this. 

Cheers,
Shaun


> -----Original Message-----
> From: sip-overload-bounces@ietf.org [mailto:sip-overload-
> bounces@ietf.org] On Behalf Of NOEL, ERIC C (ERIC C)
> Sent: Friday, April 29, 2011 8:57 AM
> To: Volker Hilt; 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)
> 
> Volker,
> 
> Wrt Phil's comment on vulnerability to sudden increases on the offered
> load at client sources, I believe the paper from Arthur Berger in IEEE
> Transactions on Automatic Control Vol 36, No2, February 1991 titled
> "Overload Control Using Rate Control: Selecting Token Bank Capacity
for
> Robustness to Arrival Rates" supports that observation.
> 
> In that paper, Figure 3 compares rate control to call gapping and to
> percent blocking. As offered load increases, rate control is the only
> algorithm that controls load close to the target. Basically Phil's
> point.
> 
> Because it is a copyrighted document, I do not think I can broadcast
on
> distribution list. However, if you cannot get a copy of the paper let
> me know and I will assist you.
> 
> Thanks,
> 
> Eric Noel
> LMTS
> AT&T Labs, Inc.
> Rethink Possible
> 
> Network Design and Performance Analysis
> 200 South Laurel Avenue, D5-3D19
> Middletown, NJ 07748
> P: 732.420.4174
> ecnoel@att.com
> 
> 
> -----Original Message-----
> From: sip-overload-bounces@ietf.org [mailto:sip-overload-
> bounces@ietf.org] On Behalf Of Volker Hilt
> Sent: Thursday, April 28, 2011 10:06 PM
> To: 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)
> 
> 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
> restriction algorithms (e.g., loss, rate and window)?
> 
> If we would mandate that, we would loose the possibility to extend the
> feedback types at a later point. And, of course, we add the complexity
> of requiring clients to implement multiple algorithms that to the
same.
> 
> > 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?
> 
> I'd also recommend to look at the results of the SIP overload control
> design team that has investigated this problem.
> 
> > 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
> neighbors. If new clients arrive, the split has to be adjusted. In
> particular if you are dealing with a large set of clients some of
which
> may be inactive for some time, this requires a quick readjustment of
> the
> allocated capacity. This topic has been discussion in the design
> considerations draft.
> 
> > 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.
> 
> Let's assume for a second you are in fact using overload control for
> this purpose and are configuring your overload control rates to match
> your SLAs. Say you have two servers A and B (each with capacity 500
> req/s) and four upstream neighbors. The SLA with each of them is that
> you accept 250 req/s.
> 
> If one of your servers goes down, your capacity is cut in half. If you
> have configured overload control to honor you SLAs, your remaining
> server will melt down within ms. Your only choice to survive this
> situation is to use overload control and cut the rates below the SLA.
> 
> Thanks,
> 
> Volker (as individual)
> 
> 
> 
> 
> > Comments please!
> > Phil Williams
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload