[sip-overload] comments on draft-ietf-soc-overload-rate-control-01

[Janet P Gunn <[e-mail]>]

These are largely editorial comments.

Sec 1
Change
  More importantly, a loss-based control cannot guarantee clients to
   produce a bounded offered load towards an overloaded server and
   requires frequent updates which may have implications for stability.
To
  More importantly, a loss-based control cannot guarantee an upper 
  bound on the offered load  from the clients towards an overloaded 
  server. It also requires frequent updates which may have implications 
  for stability.

Change 
   This document proposes extensions to [draft-ietf-soc-overload-
   control-07] so as to support a rate-based control that guarantees
   clients produce a limited upper bound to the Invite rate towards an
   overloaded server, which is constant between server updates.
To
   This document proposes extensions to [draft-ietf-soc-overload-
   control-07] to support a rate-based control that guarantees
  an upper bound on the rate, constant between server updates, of Invites 
 sent by clients towards an  overloaded server.

Also, do you really mean “Invite”, as opposed to “request”?


Change
  The  penalty for such a benefit is in terms of algorithmic complexity,
   since the overloaded server must estimate a target offered load and
   allocate a portion to each conversing client.
To
  The  tradeoff is in terms of algorithmic complexity,   since the 
overloaded 
  server must estimate a separate target for each client, rather 
  than an overall loss percentage, equally applicable to all clients.

Change
The proposed rate-based overload control algorithm mitigates
   congestion in SIP networks while adhering to the overload signaling
   scheme in [draft-ietf-soc-overload-control-07] and proposing a rate
   control in addition to the default loss-based control in [draft-
   ietf-soc-overload-control-07].
To
The proposed rate-based overload control algorithm mitigates
   congestion in SIP networks while adhering to the overload signaling
   scheme in [draft-ietf-soc-overload-control-07] and presenting a rate 
based
   control as an optional alternative  to the default loss-based control 
in [draft-
   ietf-soc-overload-control-07].

Sec 2

If, for instance, only a SIP
   client supports this specification and not the SIP server,

This doesn’t seem to be a very useful “for instance”, since the  non- 
supporting server won’t be sending any oc parameters to the supporting 
client.

The more interesting “for instance” is when the SIP server supports it and 
the SIP client doesn’t.

Sec 3.2 still needs to be fleshed out

Sec 3.3 
Suggest changing 
Per [draft-ietf-soc-overload-control-07], new clients indicate
   supported overload control algorithms to servers by inserting oc and
   oc-algo in Via header of SIP requests destined to servers.  While
   servers notify clients of selected overload control algorithm
   through the oc-algo parameter in the Via header of SIP responses to
   clients

   Support of rate-based control MUST be indicated by clients and
   servers by setting oc-algo to "rate".

To
   Per [draft-ietf-soc-overload-control-07], new clients indicate
   supported overload control algorithms to servers by inserting oc and
   oc-alg, with the names of the supported algorithms,  in Via header of 
SIP requests destined to servers. 
   The inclusion by the client of the string “rate” indicates that the 
client supports  a rate based algorithm
  Conversely,
   servers notify clients of selected overload control algorithm
   through the oc-algo parameter in the Via header of SIP responses to
   clients.  The inclusion by the server of the string “rate” indicates 
that the rate based algorithm has 
   been selected by the server.

   Support of rate-based control MUST be indicated by clients  setting 
oc-algo to "rate". Selection of  rate-based control MUST be indicated by 
servers setting oc-algo to "rate".

Sec 3.4
Add to second paragraph
The server may set the same rate for every  client, or may set a different 
rates for different clients

Third paragraph, first sentence
Change
… even though it  may only affect a particular subset … 
to 
… even though throttling   may only affect a particular subset …

Change
…since as per [draft-ietf-soc-
   overload-control-07], request prioritization is the client
   responsibility.
To
… since as per [draft-ietf-soc-
   overload-control-07],  and REQ 13 of RFC 5390, request prioritization 
is the client
   responsibility.
And add RFC  5390 to the normative references.

Last sentence of third para
Change
But when deriving this rate the server may need to
   take into account the effect of the client prioritization on the
   load it receives, e.g. CPU utilization will depend upon the
   characteristics of the requests.
To
But when deriving this rate the server may need to
   take into account  characteristics of the requests, and 
the effect of the client prioritization on the
   load it receives, e.g. the average CPU utilization  per request  under 
overload
 control may be different from the average CPU utilization under 
non-overloaded conditions

4th para
Note that the target SIP request rate is a max rate that may not be
   attained by the arrival rate at the client, and the server cannot
   assume that it will.
To
Note that the target SIP request rate is an upper bound on the rate the 
client may send requests to the server.  In many cases, the client will 
send messages at a lower rate.

5th para
Upon detection of overload, the server MUST follow the
   specifications in [draft-ietf-soc-overload-control-07] to notify its
   clients of its overload state and of the allocated target SIP
   request rate.
To
Upon detection of overload, the server MUST follow the
   specifications in [draft-ietf-soc-overload-control-07] to notify its
   clients of the allocated target SIP   request rate.

5th para
Change
   The server MUST use [draft-ietf-soc-overload-control-07] oc
   Parameter … to each of its client.
To
   The server MUST use the [draft-ietf-soc-overload-control-07] oc
   Parameter … to each of its clients. (or “to each client”)

Sec 3.5.1, 3.5.2 -  no comments because I know you are rewriting that to 
include pseudocode.

Janet