Subject: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - PLEASE COMMENT!

From: Salvatore Loreto <[email-masked]>
Date: Wed, 12 Jun 2013 16:36:17 +0300

Dear SoC WG participants

we are trying to finalize all the SIP Overload efforts before the next 
IETF meeting in Berlin.

The Overload-Rate-Control is the last wg-item we have, and in order to 
progress it,
we need people reading and reviewing and a clear evidence that people 
have done it.
Comments and especially full and deep reviews of the draft are really 
appreciate, but also simple feedback
like "I have read the draft and I think is ready for IESG" would be enough.

We haven't received any comments from the first call so we are extending 
the WGLC till Fri Jun 21th.

This is our last draft, let's make a final push to get this done.

Thanks
Salvatore

On 5/24/13 12:59 PM, Volker Hilt wrote:
> Folks,
>
> with draft-ietf-soc-overload-control-13 getting close to finalization, 
> we are ready to start the WGLC for our last remaining draft:
>
> http://www.ietf.org/id/draft-ietf-soc-overload-rate-control-04.txt
>
> The WGLC will end on Fri Jun 7.
>
> Please review the draft and send your comments to the mailing list. It 
> is very important that the WG reviews this draft. YOUR comments are 
> important - even if it is just to say you agree!
>
> This is our last draft, let's make a final push to get this done.
>
> Thanks,
>
> Salvatore and Volker
> SOC WG co-chairs
>

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 13 Jun 2013 09:49:08 -0400

(Coming out from under analysis of the Boston Bombing overload, the 
Oklahoma Tornado overload, etc.)

I am working on some more detailed comments, but here are a couple of 
higher level things

Needs to be made clearer that the "default algorithms" are simply 
"existence" examples, and that other rate based algorithms can be used.

Need to be clearer about what the constraints (how strictly they limit 
traffic) are on other algorithms (and for the default algorithms too - if 
you make TAU too big , you are not really limiting to a specific rate)

Need to make it clearer that only "T" (the target rate) is transmitted in 
the "oc" value.  The other parameters (TAU, TAU0, TAU1, TAU2) are not part 
of the message protocol. 
Are you expecting that there will be some external negotiation between the 
client and the server on appropriate values for these "tolerance" 
parameters? 
 Or are you expecting that the client will pick values for these 
parameters on its own, without involving the server in the decision?

Since they are default algorithms, it would make sense (and make it easier 
to follow) to give default, or recommended,  values for TAU, TAU0, TAU1, 
TAU2.

More later, and hoping these thunderstorms don't lead to more overloads!

Janet
.

[email-masked] wrote on 06/12/2013 09:36:17 AM:

> From: Salvatore Loreto <[email-masked]>
> To: Volker Hilt <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>
> Date: 06/12/2013 09:36 AM
> Subject: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control -
> PLEASE COMMENT!
> Sent by: [email-masked]
> 
> Dear SoC WG participants
> 

> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload

---

From: Janet P Gunn <[email-masked]>
Date: Thu, 20 Jun 2013 15:44:31 -0400

Here is my more complete review.

Pg 1

“This document proposes a   rate-based control solution to complement the 
loss-based control   defined in [draft-ietf-soc-overload-control-12].”
->
“This document proposes a   rate-based control solution to complement the 
loss-based control   defined in [draft-ietf-soc-overload-control-12], 
using the same signaling.”

Pg 3
“an  overloaded server..”
->
“an overloaded server.”
(remove extra space and extra “.”)

“…since the overloaded server must estimate   a separate target for each 
client, rather than an overall loss   percentage, equally applicable to 
all clients.”
I don’t think this is true.  There is no requirement for the “loss” 
algorithm to send the same loss percentage to all clients.  Suggest 
rewording as “ since the overloaded server is more likely  to use a 
different target (maximum rate) for each client, than the loss approach.”

Pg 4

Sec 3.2
Change order
Change
“oc: Used by SIP clients to indicate draft-ietf-soc-overload-control-
   12 support and by SIP servers to indicate the load reduction amount.

   oc parameters defined in draft-ietf-soc-overload-control-12 are
   summarized below:”
->
 “   oc parameters defined in draft-ietf-soc-overload-control-12 are
   summarized below:

oc: Used by SIP clients to indicate draft-ietf-soc-overload-control-
   12 support and by SIP servers to indicate the load reduction amount”

“… by SIP servers to notify clients of algorithm in
   effect.”
->
“… by SIP servers to notify clients of the algorithm in
   effect.”

“A non-zero value is required in conjunction with an "oc" parameter.”
->
“A non-zero value is required in conjunction for all other cases.”

Pg 5

Sec 3.3

“Conversely, servers notify clients of selected overload
   control algorithm”
->
“Conversely, servers notify clients of the selected overload
   control algorithm”

“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 by setting oc-algo to ''rate''.”

Do we need to explicitly say “the server can only set oc-algo to ‘rate’ if 
the client included ‘rate’ in its lost of supported algorithms”?

Sec 3.4

“However, the server MUST be able to evaluate periodically its
   overload state and estimate …”
->
“However, the server MUST periodically evaluate its
   overload state and estimate …”

Pg 5 – pg 6
“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. CPU utilization will depend upon the characteristics
   of the requests which would presumably allow the server to take in
   account prioritization.”

This is long and awkward.  Suggest
“When setting the maximum rate, in messages per second, for a particular 
client, the server may need take into account the workload (e.g. cpu load 
per request) of the distribution of message types from that client. 
Furthermore, because the client may prioritize the specific types of 
messages it sends while under overload restriction, this distribution of 
message types may be different from (e.g., either higher or lower cpu 
load) the message distribution for that client under non-overload 
conditions.”

Similarly
“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.”
Would be clearer as
“Note that the oc parameter for the rate algorithm is an upper bound (in 
messages per second) on the traffic sent by the client to the server.  The 
client may send traffic at a rate significantly lower  than the upper 
bound, for a variety of reasons.”

Pg 6

“Upon detection of overload, the server MUST…”
->
“Upon detection of overload, and the determination to invoke overload 
controls, the server MUST…”

Sec 3.5
Needs some introductory text, giving context for the default algorithms.
One possibility:
“In determining whether or not to transmit a specific message, the client 
may use any algorithm that limits the message rate to 1/T messages per 
second.  It may be strictly deterministic, or it may be probabilistic.  It 
may, or may not, have a tolerance factor , to allow for short bursts, as 
long as the long term rate remains below 1/ T.

The algorithm may have provisions for prioritizing traffic in accordance 
with REQ 13 of RFC5390.

If the algorithms requires other parameters (in addition to “T”, which is 
1/oc), they may be set autonomously be the client, or they may be 
negotiated independently between client and server.  In either case, the 
coordination is out of scope for this document.

The default algorithms presented here (one without provisions for 
prioritizing traffic, one with) are only examples.  Other algorithms that 
forward messages in conformance with the upper bound of 1/T messages per 
second may be used.”

3.5.1

It would be easier to follow these algorithms is you provided “default” 
(or at least “sample”) values  for the parameters TAU, TAU0, TAU1, TAU2.

Top of pg 7, need commas

“If at a new SIP request arrival the content of the bucket is less
   than or equal to the limit value TAU, then the SIP request is
   forwarded to the server; otherwise, the SIP request is rejected.”
->
“If, at a new SIP request arrival, the content of the bucket is less
   than or equal to the limit value TAU, then the SIP request is
   forwarded to the server; otherwise, the SIP request is rejected.”

“In particular at
   mean arrival rates close to 1/T,…”
->
“In particular, at
   mean arrival rates close to 1/T,”

In some places it says “X” is the “content of the bucket”, in others the 
“value of the bucket”, and in others the “occupancy of the bucket”, or 
even “the counter”.  It would be easier to follow if it were more 
consistent.

Bottom of pg 7

I am a little confused by this
“At the arrival time of the k-th new SIP request ta(k) after control
   has been activated, the content of the bucket is provisionally
   updated to the value

   X' = X - ([ta(k) - LCT])

   where X is the content of the bucket after arrival of the last
   forwarded SIP request, and LCT is the time at which the last SIP
   request was forwarded.”

First, it is an awfully long sentence, so it might be clearer if you broke 
it up.  More importantly, I am confused between the relationship between 
“ta(k)” and “LCT”.

If no messages have been dropped, is LCT = ta(k-1) ?
If n messages in a row  have been dropped, is LCT = ta(k-n-1)?

What do the square brackets ([]) mean?

Top of page 8
“When the first response from the server has been received indicating
   control activation (oc-validity>0), LCT is set to the time of
   activation, and the occupancy of the bucket is initialized to the
   parameter TAU0 (preferably configurable) which is 0 or larger but
   less than or equal to TAU.”
Does “occupancy of the bucket” = X? Clearer if you say so.

Can you explain why you set it (X?)  to TAU0, rather than leaving it at 
its current value?

Related question, if X >0 when the overload control ends, do you continue 
to process the bucket according to the algorithm, until the bucket 
empties? Or do you just send everything? 

If you are plugging along with, say oc=100 (100 messages per second) and 
then oc changes to 50 (50 messages per second) (oc-validity >0 the whole 
time), then what happens?

I would make the second  (priority based) algorithm a separate subsection, 
3.5.2.  That would make it easier to follow.  I’d also add a statement 
something like (if I am understanding this correctly):

“This section presents a priority based rate-control algorithm. Normal 
priority messages are throttled  when the transmission rate reaches R1. 
Priority messages may continue to be sent when the transmission rate 
exceeds R1 , and are not throttled until the overall (priority and normal) 
transmission rate exceeds R2 (with R2 <= oc).”

Then include some text on the relationship between  TAU 1 and TAU2, and R1 
and R2.

If I am not understanding it properly, then provide a better explanation, 
and explain how TAU1 and TAU2 relate to the explanation.

Top of pg 9

Change 
“Note that specification of a value for TAU is beyond the scope of
   this document.”
->
“Note that specification of a value for TAU, and any communication or 
coordination between servers,  is beyond the scope of
   this document.”

I don’t think “emission interval” is the right term.  Maybe 
“inter-transmission interval”?

In this “LCT:  arrival time of last conforming SIP request….”, what does 
“conforming SIP request” mean?  Do you mean the last SIP request that was 
sent to the server?

In this, “ta: arrival time of last arrival” “last” is not clear.  Do you 
mean the “most recent arrival”?  Or the “previous arrival”?

Here you say “X: current value of leaky bucket counter (initialized to 
0)”.  But earlier (unless I am confused), you said that X was initialized 
to TAU0

“  // After first arrival, calculate auxiliary variable Xp
   Xp = X - (ta - LCT);”
Do you really mean only after the FIRST arrival?  Or do you mean after 
EACH arrival?  Do you also update ta with each arrival?

What do you mean by “Accept SIP request”?  Do you mean “transmit SIP 
request?

In the priority algorithm, if I am understanding it correctly  on this 
line
“if (AnyRequestReceived && Xp <= TAU1 || PriorityRequestReceived &&
   Xp <= TAU2 && Xp > TAU1)”
Why do you need the final “Xp > TAU1” clause?  Wouldn’t it work just as 
well without it?

Top of page 11

I am not really knowledgeable about the resonant case, but it seems to me 
that in this bullet
“     . If TAU0 is chosen to be equal to TAU and all sources were to
        activate control at the same time due to an extremely high
        request rate,”
the issue is more the abrupt INCREASE in the request rate, rather than 
just the high VALUE of the request rate.

In the example in section 4, the SIP response (for the non-overloaded 
case), seems to be missing the “oc” parameter.

Janet

This is a PRIVATE message. If you are not the intended recipient, please 
delete without copying and kindly advise us by e-mail of the mistake in 
delivery. NOTE: Regardless of content, this e-mail shall not operate to 
bind CSC to any order or other contract unless pursuant to explicit 
written agreement or government initiative expressly permitting the use of 
e-mail for such purpose.

[email-masked] wrote on 06/13/2013 09:49:08 AM:

> From: Janet P Gunn/USA/CSC@CSC
> To: Salvatore Loreto <[email-masked]>
> Cc: [email-masked], "[email-masked]" <sip-
> [email-masked]>, Volker Hilt <[email-masked]>
> Date: 06/13/2013 09:49 AM
> Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-
> control - PLEASE COMMENT!
> I am working on some more detailed comments, but here are a couple 
> of higher level things 
> 
> Need to be clearer about what the constraints (how strictly they 
> limit traffic) are on other algorithms (and for the default 
> algorithms too - if you make TAU too big , you are not really 
> limiting to a specific rate) 
> 
> Need to make it clearer that only "T" (the target rate) is 
> transmitted in the "oc" value.  The other parameters (TAU, TAU0, 
> TAU1, TAU2) are not part of the message protocol. 
> Are you expecting that there will be some external negotiation 
> between the client and the server on appropriate values for these 
> "tolerance" parameters? 
> Since they are default algorithms, it would make sense (and make it 
> easier to follow) to give default, or recommended,  values for TAU, 
> TAU0, TAU1, TAU2. 
>

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Mon, 24 Jun 2013 18:09:35 -0400

Janet,

Thank you for your insightful comments.

Please see my responses:

[Janet Gunn] Needs to be made clearer that the "default algorithms" are simply "existence" examples, and that other rate based algorithms can be used.
[Eric Noel] I believe you proposed a resolution to this comment in your 6/20 detailed comments email. Note that I approved your proposed resolution there.

[Janet Gunn]  Need to be clearer about what the constraints (how strictly they limit traffic) are on other algorithms (and for the default algorithms too - if you make TAU too big, you are not really limiting to a specific rate)
[Eric Noel] Because there are several variations for rate-based overload control algorithms, it is not clear how to set such a constraint across all such variations. However, with the provided reasonable values for the proposed rate-based overload control algorithm (please see below), a constraint is implicitly provided (for the proposed algorithm).

[Janet Gunn]  Need to make it clearer that only "T" (the target rate) is transmitted in the "oc" value.  The other parameters (TAU, TAU0, TAU1, TAU2) are not part of the message protocol.
[Eric Noel] Yes, only the target rate is transmitted in the "oc" value. Section 3.5.1 specifies that "T is computed as the inverse of the rate specified in the oc value, namely T = 1 / oc-value." While in Section 4 usage example, it is stated that the overloaded element P2 "...sends the following SIP message indicating P1 should send SIP requests at a rate no greater than or equal to 150 SIP requests per seconds." Where the message oc value is set to oc=150.
=> In light of the above, do you still want to have some text added to specifically state that parameters TAU, TAU0, TAU1, TAU2 are not exchanged through the overload control scheme.
[Janet Gunn] Are you expecting that there will be some external negotiation between the client and the server on appropriate values for these "tolerance" parameters? Or are you expecting that the client will pick values for these parameters on its own, without involving the server in the decision?
[Eric Noel] Tolerance parameters defined in the default rate-based overload control algorithm are specific to that default algorithm and not expected to be negotiated between clients and servers. The expectation is that if the clients where to use the proposed default rate-based overload control algorithm, clients will be pre-provisioned with values for the tolerance parameters.

[Janet Gunn] Since they are default algorithms, it would make sense (and make it easier to follow) to give default, or recommended, values for TAU, TAU0, TAU1, TAU2.
[Eric Noel] Comment addressed in your 6/20 email.

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
[email-masked]<mailto:[email-masked]>

From: [email-masked] [mailto:[email-masked]] On Behalf Of Janet P Gunn
Sent: Thursday, June 13, 2013 9:49 AM
To: Salvatore Loreto
Cc: [email-masked]; [email-masked]; Volker Hilt
Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - PLEASE COMMENT!

(Coming out from under analysis of the Boston Bombing overload, the Oklahoma Tornado overload, etc.)

I am working on some more detailed comments, but here are a couple of higher level things

Needs to be made clearer that the "default algorithms" are simply "existence" examples, and that other rate based algorithms can be used.

Need to be clearer about what the constraints (how strictly they limit traffic) are on other algorithms (and for the default algorithms too - if you make TAU too big , you are not really limiting to a specific rate)

Need to make it clearer that only "T" (the target rate) is transmitted in the "oc" value.  The other parameters (TAU, TAU0, TAU1, TAU2) are not part of the message protocol.
Are you expecting that there will be some external negotiation between the client and the server on appropriate values for these "tolerance" parameters?
 Or are you expecting that the client will pick values for these parameters on its own, without involving the server in the decision?

Since they are default algorithms, it would make sense (and make it easier to follow) to give default, or recommended,  values for TAU, TAU0, TAU1, TAU2.

Janet
.

[email-masked]<mailto:[email-masked]> wrote on 06/12/2013 09:36:17 AM:

> From: Salvatore Loreto <[email-masked]<mailto:[email-masked]>>
> To: Volker Hilt <[email-masked]<mailto:[email-masked]>>
> Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
> Sent by: [email-masked]<mailto:[email-masked]>
>
> Dear SoC WG participants
>
> [email-masked]<mailto:[email-masked]>

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Mon, 24 Jun 2013 18:14:27 -0400

Janet,

Thank you for your thorough review and insightful comments.

[Janet Gunn] Pg 1 “This document proposes a   rate-based control solution to complement the loss-based control   defined in [draft-ietf-soc-overload-control-12].”  -> “This document proposes a   rate-based control solution to complement the loss-based control   defined in [draft-ietf-soc-overload-control-12], using the same signaling.”
[Eric Noel] Change accepted.

[Janet Gunn] Pg 3  “an  overloaded server..” -> “an overloaded server.”  (remove extra space and extra “.”)
[Eric Noel] Change accepted

[Janet Gunn] “…since the overloaded server must estimate   a separate target for each client, rather than an overall loss   percentage, equally applicable to all clients.”  I don’t think this is true.  There is no requirement for the “loss” algorithm to send the same loss percentage to all clients.  Suggest rewording as “ since the overloaded server is more likely  to use a different target (maximum rate) for each client, than the loss approach.”
[Eric Noel] Comment well taken, change accepted.

[Janet Gunn] Pg 4 Sec 3.2 Change order Change
“oc: Used by SIP clients to indicate draft-ietf-soc-overload-control- 12 support and by SIP servers to indicate the load reduction amount.   oc parameters defined in draft-ietf-soc-overload-control-12 are  summarized below:”
->  “ oc parameters defined in draft-ietf-soc-overload-control-12 are summarized below: oc: Used by SIP clients to indicate draft-ietf-soc-overload-control-12 support and by SIP servers to indicate the load reduction amount”
“… by SIP servers to notify clients of algorithm in effect.”
-> “… by SIP servers to notify clients of the algorithm in
   effect.”
“A non-zero value is required in conjunction with an "oc" parameter.”
-> “A non-zero value is required in conjunction for all other cases.”
[Eric Noel] Change accepted

[Janet Gunn] Pg 5 Sec 3.3  “Conversely, servers notify clients of selected overload control algorithm”  ->  “Conversely, servers notify clients of the selected overload control algorithm”
[Eric Noel] Change accepted

[Janet Gunn] “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 by setting oc-algo to ''rate''.”  Do we need to explicitly say “the server can only set oc-algo to ‘rate’ if the client included ‘rate’ in its list of supported algorithms”?
[Eric Noel] Proposed changed is implicitly stated in existing text. Recommend not making any changes.

[Janet Gunn] Sec 3.4 “However, the server MUST be able to evaluate periodically its overload state and estimate …” -> “However, the server MUST periodically evaluate its  overload state and estimate …”
[Eric Noel] Change accepted

[Janet Gunn] Pg 5 – pg 6 “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. CPU utilization will depend upon the characteristics of the requests which would presumably allow the server to take in account prioritization.”
This is long and awkward.  Suggest
“When setting the maximum rate FOR A PARTICULAR CLIENT, the server may need take into account the workload (e.g. cpu load per request) of the distribution of message types from that client.  Furthermore, because the client may prioritize the specific types of messages it sends while under overload restriction, this distribution of message types may be different from (e.g., either higher or lower cpu load) the message distribution for that client under non-overload conditions.”
Similarly “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.”
Would be clearer as
“Note that the oc parameter for the rate algorithm is an upper bound (in messages per second) on the traffic sent by the client to the server.  The client may send traffic at a rate significantly lower than the upper bound, for a variety of reasons.”
[Eric Noel] Changes accepted with proposed modifications embedded (in caps)

[Janet Gunn] Pg 6 “Upon detection of overload, the server MUST…” -> “Upon detection of overload, and the determination to invoke overload controls, the server MUST…”
[Eric Noel] Changes accepted

[Janet Gunn] Sec 3.5 Needs some introductory text, giving context for the default algorithms. One possibility:
“In determining whether or not to transmit a specific message, the client may use any algorithm that limits the message rate to 1/T messages per second.  It may be strictly deterministic, or it may be probabilistic.  It may, or may not, have a tolerance factor, to allow for short bursts, as long as the long term rate remains below 1/ T.
The algorithm may have provisions for prioritizing traffic in accordance with REQ 13 of RFC5390.
If the algorithms requires other parameters (in addition to “T”, which is 1/oc), they may be set autonomously BY the client, or they may be negotiated independently between client and server.  In either case, the coordination is out of scope for this document.
The default algorithms presented here (one without provisions for prioritizing traffic, one with) are only examples.  Other algorithms that forward messages in conformance with the upper bound of 1/T messages per second may be used.”
[Eric Noel] Changes accepted with proposed modification embedded (in caps)

[Janet Gunn] 3.5.1 It would be easier to follow these algorithms is you provided “default” (or at least “sample”) values for the parameters TAU, TAU0, TAU1, TAU2.
[Eric Noel] In section 3.5, we attempted to address this issue by providing guidelines on how to set these parameters. We certainly can provide sample values.
In Section 3.5.1, After “Note that specification of a value for TAU is beyond the scope of this document.” We will add “Without priority, TAU=4*T is a reasonable compromise between burst size and throttled rate adaptation at low offered rate. While reasonable values for TAU0, TAU1 & TAU2 are: TAU0 = 0, TAU1 = 1/2*TAU2 and TAU2=10*T
=> Please confirm these changes addressed your comment.

[Janet Gunn] Top of pg 7, need commas “If at a new SIP request arrival the content of the bucket is less than or equal to the limit value TAU, then the SIP request is forwarded to the server; otherwise, the SIP request is rejected.”  ->
“If, at a new SIP request arrival, the content of the bucket is less than or equal to the limit value TAU, then the SIP request is forwarded to the server; otherwise, the SIP request is rejected.”
“In particular at mean arrival rates close to 1/T,…”  -> “In particular, at mean arrival rates close to 1/T,”
[Eric Noel] Changes accepted

[Janet Gunn] In some places it says “X” is the “content of the bucket”, in others the “value of the bucket”, and in others the “occupancy of the bucket”, or even “the counter”.  It would be easier to follow if it were more consistent.
[Eric Noel] Will modify document to make more consistent

[Janet Gunn] Bottom of pg 7 I am a little confused by this “At the arrival time of the k-th new SIP request ta(k) after control has been activated, the content of the bucket is provisionally updated to the value
   X' = X - ([ta(k) - LCT])
   where X is the content of the bucket after arrival of the last forwarded SIP request, and LCT is the time at which the last SIP request was forwarded.”

1.       First, it is an awfully long sentence, so it might be clearer if you broke it up.  More importantly, I am confused between the relationship between “ta(k)” and “LCT”.

2.       If no messages have been dropped, is LCT = ta(k-1) ?

3.       If n messages in a row have been dropped, is LCT = ta(k-n-1)?

4.       What do the square brackets ([]) mean?
[Eric Noel]
1. Will try to break up sentence to ease in readability.
2. If the k-th new SIP request (arrival time ta(k)) is not rejected, then yes LCT will set to ta(k)
3. If n consecutive SIP requests are dropped, but the n+1-th plus, then LCT will be set to ta(k+n+1)
4. Square bracket seems to be superfluous. It will be removed in next version.

[Janet Gunn] Top of page 8 “When the first response from the server has been received indicating control activation (oc-validity>0), LCT is set to the time of    activation, and the occupancy of the bucket is initialized to the parameter TAU0 (preferably configurable) which is 0 or larger but less than or equal to TAU.”
Does “occupancy of the bucket” = X? Clearer if you say so.
[Eric Noel] In page 7, we stated “…X is the content of the bucket after arrival of the last forwarded SIP request”  Within the context of page 8 sentence, would replacing “and the occupancy of the bucket is initialized to” with “and the size of the bucket is initialized to” address your comment?

[Janet Gunn] Can you explain why you set it (X?)  to TAU0, rather than leaving it at its current value?
[Eric Noel] Each time the control is activated, we reset the bucket content to a configurable value TAU0.  The larger TAU0 (bounded by 0 and T+TAU) the more offered load would be accepted. If there were strong correlation between successive overload events, keeping the last used value would make sense. But since we do not have any prior knowledge on such a correlation, we opted to re-initialize the bucket size to TAU0.

[Janet Gunn] Related question, if X >0 when the overload control ends, do you continue to process the bucket according to the algorithm, until the bucket empties? Or do you just send everything?
[Eric Noel] Until client is notified by server to abate control, the client will keep controlling load towards the server. As soon as the server notifies the client to stop the control, the client should no longer control load.  This further articulated in page 6, “However, when both oc-value and oc-validity are 0, the client should immediately stop throttling.”

[Janet Gunn] If you are plugging along with, say oc=100 (100 messages per second) and then oc changes to 50 (50 messages per second) (oc-validity >0 the whole time), then what happens?
[Eric Noel] Each time the client receives a new oc value, it updates T accordingly (T = 1/oc value).  Reducing oc by 1/2 would double T and double the bucket size increment following acceptance of a new SIP request.

[Janet Gunn] I would make the second (priority based) algorithm a separate subsection, 3.5.2.  That would make it easier to follow.
[Eric Noel] Change accepted. Will add Section 3.5.2 Priority treatment.

[Janet Gunn]  I’d also add a statement something like (if I am understanding this correctly):
“This section presents a priority based rate-control algorithm. Normal priority messages are throttled  when the transmission rate reaches R1.  Priority messages may continue to be sent when the transmission rate exceeds R1 , and are not throttled until the overall (priority and normal) transmission rate exceeds R2 (with R2 <= oc).”
Then include some text on the relationship between  TAU 1 and TAU2, and R1 and R2.
If I am not understanding it properly, then provide a better explanation, and explain how TAU1 and TAU2 relate to the explanation.
[Eric Noel] The priority rate-based overload control must still limit the combined rate of priority and non-priority load (R1+R2) so that the admitted rate does not exceed rate 1/TAU.  To provide priority treatment, two tolerance parameters TAU1 & TAU2 must be introduced. In the proposed approach, TAU1 modulates deviation of combined priority and non priority arrival rates from expected inter arrival time T.  While TAU2, in effect, control how close from strict priority the control is (in the proposed approach for a fixed TAU1, the larger TAU2 the larger priority traffic bursts are accepted or the more priority traffic is accepted while conforming to the rate limit 1/TAU).
=> Please let me know if you wish to further discuss this area.

[Janet Gunn] Top of pg 9 Change  “Note that specification of a value for TAU is beyond the scope of  this document.”
-> “Note that specification of a value for TAU, and any communication or coordination between servers,  is beyond the scope of this document.”
[Eric Noel] Change accepted

[Janet Gunn]  I don’t think “emission interval” is the right term.  Maybe “inter-transmission interval”?
[Eric Noel] Yes, inter-transmission or inter-arrival time would work better.

[Janet Gunn] In this “LCT:  arrival time of last conforming SIP request….”, what does “conforming SIP request” mean?  Do you mean the last SIP request that was sent to the server?
[Eric Noel] Yes, let’s replace “conforming” by  “last SIP request that was sent to the server”

[Janet Gunn] In this, “ta: arrival time of last arrival” “last” is not clear.  Do you mean the “most recent arrival”?  Or the “previous arrival”?
[Eric Noel] ta is the arrival time of the SIP request the algorithm is operating upon, the last arrival or most recent arrival if this works better.

[Janet Gunn] Here you say “X: current value of leaky bucket counter (initialized to 0)”.  But earlier (unless I am confused), you said that X was initialized to TAU0
[Eric Noel] Good catch, should be initialize to TAU0

[Janet Gunn]
“  // After first arrival, calculate auxiliary variable Xp
   Xp = X - (ta - LCT);”
Do you really mean only after the FIRST arrival?  Or do you mean after EACH arrival?  Do you also update ta with each arrival?
[Eric Noel] Should be “After most recent arrival” (with your suggested terminology above)

[Janet Gunn]What do you mean by “Accept SIP request”?  Do you mean “transmit SIP request?
[Eric Noel] Yes. Will replace text to make it clearer

[Janet Gunn]
In the priority algorithm, if I am understanding it correctly  on this line
“if (AnyRequestReceived && Xp <= TAU1 || PriorityRequestReceived &&
   Xp <= TAU2 && Xp > TAU1)”
Why do you need the final “Xp > TAU1” clause?  Wouldn’t it work just as well without it?
[Eric Noel] Yes, Xp > TAU1 is redundant and will be removed

[Janet Gunn]
Top of page 11  I am not really knowledgeable about the resonant case, but it seems to me that in this bullet
“     . If TAU0 is chosen to be equal to TAU and all sources were to
        activate control at the same time due to an extremely high
        request rate,”
the issue is more the abrupt INCREASE in the request rate, rather than just the high VALUE of the request rate.
[Eric Noel] Correct

[Janet Gunn] In the example in section 4, the SIP response (for the non-overloaded case), seems to be missing the “oc” parameter.
[Eric Noel] Yes, 100-TRYING should have the following parameters set oc=0;oc-algo="rate";oc-validity=0

Please note, we will wait until expiration of WGLC prior updating our draft RFC. Once again your comments and/or suggestions are most appreciated.

Thanks

Eric Noel
AT&T Labs, Inc.
Rethink Possible

From: [email-masked] [mailto:[email-masked]] On Behalf Of Janet P Gunn
Sent: Thursday, June 20, 2013 3:45 PM
To: Janet P Gunn
Cc: [email-masked]; [email-masked]; Volker Hilt
Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control - PLEASE COMMENT!

Pg 1

“This document proposes a   rate-based control solution to complement the loss-based control   defined in [draft-ietf-soc-overload-control-12].”
->
“This document proposes a   rate-based control solution to complement the loss-based control   defined in [draft-ietf-soc-overload-control-12], using the same signaling.”

Pg 3
“an  overloaded server..”
->
“an overloaded server.”

“…since the overloaded server must estimate   a separate target for each client, rather than an overall loss   percentage, equally applicable to all clients.”
I don’t think this is true.  There is no requirement for the “loss” algorithm to send the same loss percentage to all clients.  Suggest rewording as “ since the overloaded server is more likely  to use a different target (maximum rate) for each client, than the loss approach.”

Pg 4

Sec 3.2
Change order
Change

Pg 5

Sec 3.3

Do we need to explicitly say “the server can only set oc-algo to ‘rate’ if the client included ‘rate’ in its lost of supported algorithms”?

Sec 3.4

Pg 5 – pg 6
“But when deriving this

This is long and awkward.  Suggest
“When setting the maximum rate, in messages per second, for a particular client, the server may need take into account the workload (e.g. cpu load per request) of the distribution of message types from that client.  Furthermore, because the client may prioritize the specific types of messages it sends while under overload restriction, this distribution of message types may be different from (e.g., either higher or lower cpu load) the message distribution for that client under non-overload conditions.”

Similarly
“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.”
Would be clearer as
“Note that the oc parameter for the rate algorithm is an upper bound (in messages per second) on the traffic sent by the client to the server.  The client may send traffic at a rate significantly lower  than the upper bound, for a variety of reasons.”

Pg 6

“Upon detection of overload, the server MUST…”
->
“Upon detection of overload, and the determination to invoke overload controls, the server MUST…”

Sec 3.5
Needs some introductory text, giving context for the default algorithms.
One possibility:
“In determining whether or not to transmit a specific message, the client may use any algorithm that limits the message rate to 1/T messages per second.  It may be strictly deterministic, or it may be probabilistic.  It may, or may not, have a tolerance factor , to allow for short bursts, as long as the long term rate remains below 1/ T.

The algorithm may have provisions for prioritizing traffic in accordance with REQ 13 of RFC5390.

If the algorithms requires other parameters (in addition to “T”, which is 1/oc), they may be set autonomously be the client, or they may be negotiated independently between client and server.  In either case, the coordination is out of scope for this document.

The default algorithms presented here (one without provisions for prioritizing traffic, one with) are only examples.  Other algorithms that forward messages in conformance with the upper bound of 1/T messages per second may be used.”

3.5.1

It would be easier to follow these algorithms is you provided “default” (or at least “sample”) values  for the parameters TAU, TAU0, TAU1, TAU2.

Top of pg 7, need commas

“In particular at

In some places it says “X” is the “content of the bucket”, in others the “value of the bucket”, and in others the “occupancy of the bucket”, or even “the counter”.  It would be easier to follow if it were more consistent.

Bottom of pg 7

   X' = X - ([ta(k) - LCT])

First, it is an awfully long sentence, so it might be clearer if you broke it up.  More importantly, I am confused between the relationship between “ta(k)” and “LCT”.

Top of page 8

Can you explain why you set it (X?)  to TAU0, rather than leaving it at its current value?

Related question, if X >0 when the overload control ends, do you continue to process the bucket according to the algorithm, until the bucket empties? Or do you just send everything?

If you are plugging along with, say oc=100 (100 messages per second) and then oc changes to 50 (50 messages per second) (oc-validity >0 the whole time), then what happens?

I would make the second  (priority based) algorithm a separate subsection, 3.5.2.  That would make it easier to follow.  I’d also add a statement something like (if I am understanding this correctly):

“This section presents a priority based rate-control algorithm. Normal priority messages are throttled  when the transmission rate reaches R1.  Priority messages may continue to be sent when the transmission rate exceeds R1 , and are not throttled until the overall (priority and normal) transmission rate exceeds R2 (with R2 <= oc).”

Then include some text on the relationship between  TAU 1 and TAU2, and R1 and R2.

If I am not understanding it properly, then provide a better explanation, and explain how TAU1 and TAU2 relate to the explanation.

Top of pg 9

Change
“Note that specification of a value for TAU is beyond the scope of
   this document.”
->
“Note that specification of a value for TAU, and any communication or coordination between servers,  is beyond the scope of
   this document.”

I don’t think “emission interval” is the right term.  Maybe “inter-transmission interval”?

In this “LCT:  arrival time of last conforming SIP request….”, what does “conforming SIP request” mean?  Do you mean the last SIP request that was sent to the server?

In this, “ta: arrival time of last arrival” “last” is not clear.  Do you mean the “most recent arrival”?  Or the “previous arrival”?

Here you say “X: current value of leaky bucket counter (initialized to 0)”.  But earlier (unless I am confused), you said that X was initialized to TAU0

“  // After first arrival, calculate auxiliary variable Xp
   Xp = X - (ta - LCT);”
Do you really mean only after the FIRST arrival?  Or do you mean after EACH arrival?  Do you also update ta with each arrival?

What do you mean by “Accept SIP request”?  Do you mean “transmit SIP request?

In the priority algorithm, if I am understanding it correctly  on this line
“if (AnyRequestReceived && Xp <= TAU1 || PriorityRequestReceived &&
   Xp <= TAU2 && Xp > TAU1)”
Why do you need the final “Xp > TAU1” clause?  Wouldn’t it work just as well without it?

Top of page 11

I am not really knowledgeable about the resonant case, but it seems to me that in this bullet
“     . If TAU0 is chosen to be equal to TAU and all sources were to
        activate control at the same time due to an extremely high
        request rate,”
the issue is more the abrupt INCREASE in the request rate, rather than just the high VALUE of the request rate.

In the example in section 4, the SIP response (for the non-overloaded case), seems to be missing the “oc” parameter.

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.

[email-masked]<mailto:[email-masked]> wrote on 06/13/2013 09:49:08 AM:

> To: Salvatore Loreto <[email-masked]<mailto:[email-masked]>>
> Cc: [email-masked]<mailto:[email-masked]>, "[email-masked]<mailto:[email-masked]>" <sip-
> [email-masked]<mailto:[email-masked]>>, Volker Hilt <[email-masked]<mailto:[email-masked]>>