[sip-overload] Proposals for a modified soc overload control spec to support multiple (client restriction) algorithms

[<[e-mail]>]

Vijay,

As I indicated last week, I am submitting more details for discussion concerning my proposal to make client source restriction algorithms mandatory, including a possible way in which the draft spec could change, which is helpful to focus on the implications.

Clearly there are a variety of ways in which the specification could be revised to support mandatory algorithms. As a starting point I have taken an approach that I think fits closely with the current spec. Therefore "oc" is still used to indicate support for overload control by the client, but now in response carries the control parameter value for the server's chosen algorithm. The "oc-algo" still identifies the algorithm dictated by the server, but is only used in one direction. Other ways of revising the spec may be thought to be more appropriate or succinct.

Notes on the attachments:
------------------------

I have shown suggested additions and deletions in

    draft-ietf-soc-overload-control-02 revisions sections 3-8.htm

with them accepted in

    draft-ietf-soc-overload-control-02 accepted sections 3-8.htm

but I haven't sorted out formatting.

I have only indicated changes between sections 3 and 8 inclusive, but not beyond that, although they would need to be checked.

Whereas for the loss-based algorithm a value of 0(%) implies 'admit all' ('no rejections' or 'no control applied') there isn't a convenient equivalent default control parameter value for the rate-based method that has the same meaning, i.e. an infinite rate would be necessary. For this reason there is no longer default parameter, and instead a value of the "oc-validity" parameter that is not positive would have the effect of no control. Alternatively it would be worth considering the reciprocal of the rate as the parameter, which has the advantage that the admission rate would be a decreasing function of the parameter, in line with the proportional rejection (loss-based) method. It can roughly be interpreted as the minimum average time between admissions (but this should not imply a particular algorithm).

Most of section 4.2 concerning negotiation between client and server to establish the agreed algorithm has disappeared. Since it is possible that the overloaded server could support use of more than one algorithm, and switch between them, the text concerning frequent change of algorithm could still apply, and thus this specific part could be retained. The wording would be different, since it is not a negotiation. It would become a requirement that the server does not change algorithm 'too frequently' (requiring some qualification).

It would still be possible to restrict the list of mandatory algorithms to loss-based and rate-based as you have intimated, although I suggest still including windowing. I am conscious that for window-based the throughput will be sensitive to server and network (round-trip) response time, and that the method and frequency of feedback (to update outstanding window occupancy rather than control parameter) would be critical. I have not read the past discussions about this method in SOC, so I would need to look back at the prior dialogue...

Further work: The actual adapted control parameter needs to be confirmed for the rate-based and window-based methods. E.g. for windowing the analogue to the rate-based rate (or rather its reciprocal) is the token size (rather than the window size). This is relevant to section 6, but it also looks like section 8 needs some further work in any case. Furthermore, for all algorithms there are additional parameters that would not normally be adapted when control is active, which also have relevance to the use of priorities alluded to in section 8, and include various thresholds. They could be configured on the client as perhaps suggested by the current text, or alternatively under control of the server. If the latter approach was taken they would have to be included by an additional message component.

The original reasons that I outlined to support the rate-based method
---------------------------------------------------------------------

were as follows (see http://www.ietf.org/mail-archive/web/sip-overload/current/msg00600.html for more detailed arguments):

    * Practical issues [Difficulty of getting alternative algorithms deployed if not mandatory];

    * Performance limitations [Of 'loss-based' or proportional rejection];

    * The need to support precise capacity guarantees.

There are some other factors that it is worth highlighting here:

Complexity: This  has been raised before. In terms of the specification there is a trade-off between having (A) a single mandatory source restriction algorithm and the others optional (current), and (B) making them all mandatory (my proposal). For (A) there has to be support for negotiation of the algorithm between the client and the overloaded server. For (B) this is no longer necessary, because the overloaded server (master) dictates the algorithm used by the client (slave). But now each client must support all identified algorithms. However these are algorithms that have been known for a long time and are widely deployed and therefore should not be difficult to agree their specification.

Deployment in simple or nascent networks: Some SIP servers may have low connectivity (in terms of numbers of routes) and it may be known that there is little variation in session workload, so that a maximum constant request arrival rate can be derived to give adequate performance (utilisation and response times). In such situations it may be difficult to justify a fully adaptive SIP overload control, and static rates on routes may be acceptable, which can be permanently allocated by an appropriately long "oc-validity" value (periodically refreshed). With proportional rejection (loss-based) the proportion rejected must be adapted according to the load offered at sources in order to constraint to a maximum arrival rate and provide effective protection, and so permanent static allocation will not work. Admittedly in this case the method of adaptation can be made very simple by having a configured static maximum rate at the overloaded server, and measuring the actual arrival rate of requests gives the required (simple) method of adaptation, so this argument is not a strong one. But one of the differences is the need to measure the arrival rate and update control sufficiently frequently for the loss-based algorithm. Also, the static rate type of deployment allows a nascent network which may have low connectivity to evolve to support adaptive control as the network evolves.

Regards,

Phil Williams