Subject: [sip-overload] draft-ietf-soc-overload-control: Further comments on draft 05 (and 06)

From: <[email-masked]>
Date: Thu, 5 Jan 2012 14:48:42 +0000

Vijay,

Thanks for producing draft 06 - I have a few further remarks that apply to drafts 05 as well.

I share Janet's concerns about the following wording in 5.2. (Creating and updating the overload control):

   ... A SIP server SHOULD use a shorter "oc-validity" time
   if its overload status varies quickly and MAY use a longer "oc-
   validity" time if this status is more stable.

Your correspondence with Janet:

> > In selecting an oc-validity value, you should also consider the time
> > interval for requests form EACH upstream SIP client.
> >
> > As an extreme example, consider a case where you have thousands of
> > upstream SIP clients, and each one sends a message, typically, once a
> > second. Even if you are adjusting your oc value every 10
> > milliseconds, you want an oc-validity of at least a second.
> > Otherwise, every time a client gets ready to transmit, it will have
> > an expired oc value, and won't throttle.
> >
> > Something like " A SIP server MAY use a shorter "oc-validity" time if
> > each upstream SIP client attempts to send messages at a high rate,
> > and SHOULD use a longer "oc- validity" time if each SIP client
> > operates at a lower rate."
>
> I think your point is valid, but shouldn't this behaviour be
> specified more appropriately in the rate-based draft?  Section 5
> in draft-ietf-soc-overload-control-05 outlines general behaviour,
> not one specific to either rate- or loss-based.

For me adding any words of guidance about the length of oc-validity (for any client algorithm) is fraught with potential issues because update frequency/magnitude is a non-trivial subject that affects control stability, and is dependent upon several factors, including as Janet has pointed out, with the response mode of feedback, the number of client sources, their rates and also the potential for a client to turn off control before a SIP message is sent. (I'm not keen on a default oc-validity value, although I can live with it, particularly one as short as 500ms, since it allows the implementer to make a decision which is not based upon proper analysis). The problem with the current wording is that one of the indications of control instability is that overload status varies quickly, and making more frequent updates may exacerbate this and increase instability (resulting in poor response time and throughput). In essence the problem is that responsiveness to changing load requires more frequent/larger updates (especially for loss-based proportional rejection), whereas stability requires less frequent/smaller updates, and the optimum lies in-between.

One option would be to remove the sentence altogether.  Alternatively it could be replaced with wording that is less prescriptive but which gives some warning, e.g.

A SIP server SHOULD specify an oc-validity time that is responsive to changing client originated traffic rates, but not too short as to introduce instability. This is a complex subject and outside the scope of this specification.

What do you think?

Whilst on the subject of oc-validity, there is a minor issue with the wording in

4.1.  The oc parameter

   The downstream server MUST add a value to the "oc" parameter in the
   response going upstream.  Inclusion of a value to the parameter
   represents two things: one,...  Second, if the value added by the
   server is non-zero, it indicates (to the client) that the server
   wants to perform overload control.

I.e., if oc>0 but oc-validity=0, which is valid, then the server does not want to perform overload control, (e.g. this is a possible way that the rate-based method would terminate control, by leaving oc at the last +ve value whilst setting oc-validity=0). The wording could be changed as follows:

   The downstream server MUST add a value to the "oc" parameter in the
   response going upstream.  Inclusion of a value to the parameter
   represents two things: one,...  Second, if overload control is active, then it indicates the level of control to be applied.

Or something similar.

Regards,

Phil

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 05 Jan 2012 13:38:12 -0600

> Thanks for producing draft 06 - I have a few further remarks that apply

Phil: Thank you for your comments.  Please see inline.

> I share Janet’s concerns about the following wording in 5.2. (Creating
> and updating the overload control):
[...]

> For me adding any words of guidance about the length of oc-validity (for
> any client algorithm) is fraught with potential issues [...]
> One option would be to remove the sentence altogether. Alternatively it
> could be replaced with wording that is less prescriptive but which gives
> some warning, e.g.
>    A SIP server SHOULD specify an oc-validity time that is responsive to
>    changing client originated traffic rates, but not too short as to
>    introduce instability. This is a complex subject and outside the scope
>    of this specification.

Works for me.  Unless someone indicates otherwise, I will make this
change.

One more change below.

> Whilst on the subject of oc-validity, there is a minor issue with the
[....]

> The wording could be changed as follows:
>   represents two things: one,... Second, if overload control is active,
>   then it indicates the level of control to be applied.

I think that is okay.  Again, unless someone indicates otherwise, I will
make this change as well in the next revision.

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/