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

[Volker Hilt <[e-mail]>]

Eric,

what makes you think the problems described in this paper apply to SIP 
overload control? None of the simulations (including yours) did show 
problems with loss-based control. Do you have results that replicate 
these issues in a SIP network? What is missing?

Volker




On 4/29/2011 8:56 AM, NOEL, ERIC C (ERIC C) wrote:
> 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 [e-mail]
>
>
> -----Original Message----- From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Volker Hilt Sent:
> Thursday, April 28, 2011 10:06 PM To: [e-mail] 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 [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload