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

["NOEL, ERIC C (ERIC C)" <[e-mail]>]

Janet,

Thanks for your comments. Please see below our response.

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Network Design and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174
[e-mail]<mailto:[e-mail]>

From: [e-mail] [mailto:[e-mail]] On Behalf Of Janet P Gunn
Sent: Tuesday, May 01, 2012 4:02 PM
To: [e-mail]
Subject: [sip-overload] comments on draft-ietf-soc-overload-rate-control-01

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.
> OK

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”?
>OK, will also change “Invites” to “requests”.

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.
>OK

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].
>OK

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.
>Please note this paragraph is identical to that in draft-ietf-soc-overload-control-08. We rather keep as is until draft-ietf-soc-overload-control-08 gets modified.

Sec 3.2 still needs to be fleshed out
>Will be addressed in next version.

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".
>OK

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
>OK

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

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.
>OK

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
>OK

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.
> Suggested writing is different than original paragraph meaning. Originally that paragraph stated the server should not assume the arrival rate at client will exceed the server target rate. Your suggested change does away with the observation on the arrival rate at client and focuses on the arrival rate presented by the client to the server.
Was that the intent?

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.
>OK

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”)
>OK

Sec 3.5.1, 3.5.2 -  no comments because I know you are rewriting that to include pseudocode.
>OK. Pseudo code will be added in next version.


Janet













From: [e-mail] [mailto:[e-mail]] On Behalf Of Janet P Gunn
Sent: Tuesday, May 01, 2012 4:02 PM
To: [e-mail]
Subject: [sip-overload] comments on draft-ietf-soc-overload-rate-control-01

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