Subject: [sip-overload] draft-ietf-soc-overload-control: Comments on the default 'loss' algorithm draft 05 (and 06)

From: <[email-masked]>
Date: Fri, 20 Jan 2012 10:04:37 +0000

Vijay,

Thanks for producing the recently revised drafts. Apologies for being slow but I have been tied up with other work.

I have a couple of more serious issues concerning Section 6.3: Default algorithm for loss-based overload control.

There are two problems here:

1) The apparent simplicity in the description that the received probability of rejection ("oc" value) should be mapped to a value for first category (low priority) by dividing by the proportion of that category belies the additional complexity and issues concerning measuring the proportion of each category, and applying that mapping. Such measurement is not straightforward because it is subject to issues of accuracy/instability - most problematic of all is the switch from not rejecting any of the second category (high priority) to not rejecting any of the first category (low priority), i.e. when the proportion of the first category becomes very low. Furthermore these proportions could be very bursty, e.g. consider a mass clearing of sessions or a sudden surge of high priority requests (e.g. an emergency). If a specific method is to be described then I think that it should be one that does not suffer from these drawbacks.

2) The issue already highlighted by Eric concerning the ramifications of differing client's view and server's view of relative priorities (categories) of requests.

Although both of these issues could be avoided by simply removing the description of category/priority differentiation, it is hard to see how this can be avoided in any realistic network, for two reasons:
*       It is required that the computed rejection probability ("oc" value)  should apply to all requests. But you wouldn't want to reject all requests indiscriminately because of the (generally) more serious consequences of rejecting mid-session requests;
*       Some networks will want to distinguish between ordinary and emergency calls (i.e. differentiation between Invites).

But all is not lost.

Regarding 1) one approach would be to make the description less prescriptive. Unfortunately this could result in implementations that perform very poorly for the reasons I have highlighted above. Alternatively it is possible to design a scheme whereby the admission/rejection decision is done on each arrival in such a way that the transition from one proportion to another preserves the "oc" probability for all requests, without the need for direct computation of the proportion. This can be modelled as a birth-death Markov process in steady-state, which is straightforward since rejection is random and memory-less and assuming that the probability of an arrival being of either category is random (but fixed). We are happy to submit this as a method, and I can provide a document describing it. It could be fairly succinctly described purely in text.

Regarding point 2) I have done some analysis that proves that the usual 'exact' method (i.e. assuming the offered client rates remain constant for the next update) of updating to the required oc value at the server for any plausible method of adaptation at the server based upon CPU utilisation, will not work in general, and even if inexact (i.e. a recursive method) there is generally a problem of convergence, depending on the relative sizes of the utilisation for the different categories of request. This would not be the case for a server method that only measures requests rates (and not say CPU utilisation), but unfortunately given the sometimes extreme variability of processing for different requests types this can be very inefficient. Incidentally, this request categorisation issue is also applicable to the rate-based method, which has priorities already defined.

I can provide more detail about these for discussion, but I will need perhaps week to write up the latter.

Views?

Regards,

Phil

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 24 Jan 2012 09:56:17 -0600

On 01/20/2012 04:04 AM, [email-masked] wrote:
> Vijay,
> Thanks for producing the recently revised drafts. Apologies for being
> slow but I have been tied up with other work.

Phil: No worries, and thanks for a careful read.  Delay in response
on my part is due to the same problem (other work).

> I have a couple of more serious issues concerning Section 6.3: Default
> algorithm for loss-based overload control.
> There are two problems here: [...]

Regarding (1), why don't we do this: you can put forth some text on
the list that describes the steady-state Markov process that can
be used in a sample algorithm.  We can fine tune it and put the text
into the draft as your contribution.

Regarding (2), there is nothing in the new S5.3 that restricts the
computation of the "oc" value to CPU utilization.  As such, I am not
sure what we need to do to S5.3 beyond what we agreed on the list
[1]

[1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00707.html

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: <[email-masked]>
Date: Tue, 31 Jan 2012 16:41:02 +0000

Vijay,

Regarding issue (1), at the moment I don't have time to distil the message category/priority client method into text for section 6.3, so in the meantime I am attaching a document that describes and analyses it, written by my colleague Nick Stewart. I'll translate into code when I get a chance, unless anyone else would like to volunteer? In any case this should be more immediately intelligible than a pure textual description. I can provide the expressions steady-state probabilities if anyone would like them, but there is a graph on the last page. Please note that this is not patented.

Regarding (2), I will have to write up some analysis (soon) that I have done in order to demonstrate the issue and enable further debate.

Regards,

Phil

> -----Original Message-----
> From: Vijay K. Gurbani [mailto:[email-masked]]
> Sent: 24 January 2012 15:56
> To: Williams,PM,Phil,DEV6 R
> Cc: [email-masked]; [email-masked]
> Subject: Re: draft-ietf-soc-overload-control: Comments on the default
> 'loss' algorithm draft 05 (and 06)
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 31 Jan 2012 12:11:06 -0600

On 01/31/2012 10:41 AM, [email-masked] wrote:
> Vijay,
>
> Regarding issue (1), at the moment I don't have time to distil the
> message category/priority client method into text for section 6.3, so
> in the meantime I am attaching a document that describes and analyses
> it, [...]

Phil: I am afraid that simply providing a reference to a document
will end up slowing the process.  I am sure you can appreciate that
time is at a premium for all parties involved.  If you feel that
something does not work in the S6.3 algorithm, I am happy to work with
you to remedy that.

Some issues that you raised on your email [2] are already attended to
by the S6.3 algorithm, more specifically, what to do when proportion of
requests in the rejection category are exhausted.  Furthermore, the
algorithm of S6.3 is a reference algorithm, it is not a mandatory-
to-implement algorithm.  Implementations are free to use their own
algorithm as long as it produces results apropos to the loss rate.

Certainly, the algorithm in S6.3 has been sitting on the list for a
long time --- going back to July 2010 [1].  What you see in S6.3
is essentially a distillation of [1], updated with the experience and
insights we have gained on the overload control work since then.

> Regarding (2), I will have to write up some analysis (soon) that I
> have done in order to demonstrate the issue and enable further
> debate.

I repeat my previous assertion that there is nothing in the new S5.3
that restricts the computation of the "oc" value to CPU utilization.
As such, I don't think we need to do to S5.3 beyond what we agreed
on the list [3], which has been reflected in the current draft.

[1] www.ietf.org/mail-archive/web/sip-overload/current/msg00318.htm
[2] www.ietf.org/mail-archive/web/sip-overload/current/msg00714.html
[3] www.ietf.org/mail-archive/web/sip-overload/current/msg00707.html

Thanks,

- vijay