[sip-overload] Comments on draft-ietf-soc-overload-control-03: oc and oc-validity

[<[e-mail]>]

Vijay et al,

I have been reviewing draft-ietf-soc-overload-control-03 and have a few comments and proposals.

Some of the text referring to oc and oc-validity from different sections is rather ambiguous and sometimes inconsistent with assumptions implicitly being made during recent dialogues. And whilst reviewing this, it has highlighted a few questions for me, i.e. how do we want a server to:
*       indicate that there isn't any overload, i.e. control is not required,
*       immediately terminate control when it has previously been active?

We have debated the second of these recently and Vijay has included oc-validity=0 explicitly in draft 03 to cover it.

So I have put together some notes and proposals for discussion.

Specific text
-------------------

Consider:

4.3.  The oc-validity parameter
   ...
   A non-zero value for the "oc-validity" parameter MUST only be present
   in conjunction with an "oc" parameter.

Does this mean "oc" parameter value, or just the presence of "oc"? If a value is not provided a possible interpretation is to leave any control applied with the prior value and restart the oc-validity time interval.
In addition, although the above does not prohibit having oc-validity=0 without an "oc" parameter, later text would do so:

5.1.  Creating and updating the overload control parameters
   ...
   The "oc-validity" parameter MUST NOT be used in a Via header that did not
   originally contain an "oc" parameter when received...

although what follows immediately this suggests that it may be permissible:

                                                                                 ...Furthermore,
   when a SIP server receives a request with the topmost Via header
   containing only an "oc-validity" parameter without the accompanying
   "oc" parameter, it MUST ignore the "oc-validity"

[Aside: This is rather confusing since in this context 'SIP server' should be 'SIP client'. Can we change this?]

We also have, if the SIP client has previously added an "oc" parameter:

4.1.  The oc parameter
   ...
   The downstream server MUST add a value to the "oc" parameter in the
   response going upstream; this value represents a metric by which the
   requests arriving at the downstream server should be reduced.

But do we really need or want to make the addition of a value mandatory? E.g. when a server deems that control is inactive it would be unnecessary. I recall that this has been implicitly assumed in some recent dialogue in any case.

Some proposals
-------------------------

*       Most of the time overload will not be present, so why not allow the server to omit an oc value even if the client has inserted oc (currently forbidden)? If this method is not adopted then inactive overload would otherwise have to be indicated by sending oc-validity=0, since for some client restriction algorithms, such as rate-based, there is no natural 'off' oc value;
*       Currently in 4.3 there is no statement when the oc-validity has to be added, it just states 'is inserted'. Should this be made more precise?
*       We could allow the oc-validity to be added with an oc parameter, but without an oc parameter value. If control is not active at the client, then again it would be ignored (case above). If control is active, then if oc-validity>0 the oc-validity timer is restarted without changing the oc value; if oc-validity=0 control is terminated. [We could also allow the oc-validity to be added in the absence of an any oc parameter, and what is currently in the latter part of 5.1 assures us that it will be ignored, although the wording may need to be made more precise].

Views?

Regards,

Phil Williams