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

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

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.

[e-mail] wrote on 06/13/2013 09:49:08 AM:

> From: Janet P Gunn/USA/CSC@CSC
> To: Salvatore Loreto <[e-mail]>
> Cc: [e-mail], "[e-mail]" <sip-
> [e-mail]>, Volker Hilt <[e-mail]>
> Date: 06/13/2013 09:49 AM
> Subject: Re: [sip-overload] WGLC: draft-ietf-soc-overload-rate-
> control - PLEASE COMMENT!
> Sent by: [e-mail]
> 
> (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
> . 
> 
> [e-mail] wrote on 06/12/2013 09:36:17 AM:
> 
> > From: Salvatore Loreto <[e-mail]> 
> > To: Volker Hilt <[e-mail]> 
> > Cc: "[e-mail]" <[e-mail]> 
> > Date: 06/12/2013 09:36 AM 
> > Subject: [sip-overload] WGLC: draft-ietf-soc-overload-rate-control -
> > PLEASE COMMENT! 
> > Sent by: [e-mail] 
> > 
> > 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
> > >
> > 
> > 
> > _______________________________________________
> > sip-overload mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/sip-overload
> _______________________________________________
> sip-overload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload