Re: [sip-overload] AD review of draft-ietf-soc-overload-rate-control

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

Richard,

Thanks for spending the time reviewing the draft. Please see below my proposed resolutions:

MAJOR:
Section 2. "The normative statements in this specification ... that does not support this specification."
This paragraph seems tautological to me.  "An implementation must support this protocol only if it supports this protocol."  Are you trying to say something different, maybe clarifying that requirements apply to the client and the server separately?  Or can this paragraph be deleted?
=> EN:  I will delete this paragraph. Note that this paragraph is identical to the one in section 2 of [draft-ietf-soc-overload-control-15]

Section 3.4. "server must allocate"
This isn't actually true, is it?  The server could set oc=0, in which case the client would send no messages.  This seems more like a suggestion, "should".
=> EN:  For the rate algorithm to operate optimally (maximize carried load while protecting the overloaded server), the server is required to allocate the estimated target SIP request rate to each of its client. Presumably it could set oc=0 to some of the clients as long as the combined oc equals the target rate. That is why we used a “must” in the text.

Section 3.5. "1/T"
The parameter T is not defined before this.  Suggest adding a paragraph to the beginning of this section of the form
"""
The "oc" parameter defines the maximum number of messages per second that the client may send to the server.  In the below discussion, we will instead refer to the arrival rate T = 1/oc-value.
"""
=>EN: Yes we need to define T before introducing it. Would the following text work?
“In determining whether or not to transmit a specific message, the client may use any algorithm that limits the message rate to the "oc" parameter in units of messages per second. For ease of discussion, we define T = 1/["oc" parameter] as the target inter-SIP request interval.”

Section 6.
I expect that this section is a little too minimal to get past the Security ADs.  I would suggest a few more words, of the form:
"""
Aside from the resonance concerns discussed in Section 3.5.3, this mechanism does not introduce any security concerns beyond the general overload-control security issues discussed in [draft-ietf-soc-overload-control-15].  Methods to mitigate the risk of resonance are discussed in Section 3.5.3.
"""
=> EN:  Will modify as suggested

MINOR / EDITORIAL:
Section 3.2.
It would be very helpful if you could include a brief example Via header at the end of this section, showing how the oc-algo and oc parameters are set to indicate a particular level of rate control.
=> EN:  Would a reference to section 4 examples suffices?  “Consult Section 4 for an illustration of the via header oc parameters usage.”

Section 3.4. "is the client responsibility" -> "is the client's responsibility"
=> EN: Will modify as suggested

Section 3.5.1. "negotiated independently" -> "negotiated out of band"
"Independently" suggests (to me) that the client and server do it independently of one another.
=> EN: Would the following modification be acceptable “…or they may be negotiated between client and server independently of the SIP based overload control solution.”

Section 3.5.1. "any other equivalent algorithm" -> "any other algorithm meeting the upper bound of 1/T messages per second"
Also, this seems redundant with the previous paragraph.  Can one of them be deleted?
=>EN:  I will delete the first reference and make the following modification in the second one: “…the client MAY use the proposed default algorithm for rate-based control or any other equivalent algorithm that forward messages in conformance with the upper bound of 1/T messages per second.”

Section 3.5.1. "Servers with a very large number of clients..."
It seems odd for this paragraph to be written in terms of server benefit, since clients are the ones that choose TAU values.  Rephrase as guidance to clients, or optionally what the server might tell clients if there's an out-of-band way for them to configure this?
=>EN:  Clients select (operator pre provisioning or out of band client-server negotiation) TAU to maximize carried load at servers while protecting servers from overload.  That is why this paragraph is written in terms of server benefits. In light of this information, would you agree to keep the text as is?

Thank you again,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Optimization, Reliability and Customer Analytics
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174
[e-mail]<mailto:[e-mail]>

From: Richard Barnes [mailto:[e-mail]]
Sent: Friday, August 08, 2014 4:55 PM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
Subject: AD review of draft-ietf-soc-overload-rate-control

I have reviewed this document in preparation for IETF LC.  Overall, it's a nice read, thanks!  I have requested LC, and there are a few comments below that I would like you to address along with any LC comments.
--Richard

MAJOR:
Section 2. "The normative statements in this specification ... that does not support this specification."
This paragraph seems tautological to me.  "An implementation must support this protocol only if it supports this protocol."  Are you trying to say something different, maybe clarifying that requirements apply to the client and the server separately?  Or can this paragraph be deleted?
Section 3.4. "server must allocate"
This isn't actually true, is it?  The server could set oc=0, in which case the client would send no messages.  This seems more like a suggestion, "should".
Section 3.5. "1/T"
The paramter T is not defined before this.  Suggest adding a paragraph to the beginning of this section of the form
"""
The "oc" parameter defines the maximum number of messages per second that the client may send to the server.  In the below discussion, we will instead refer to the arrival rate T = 1/oc-value.
"""
Section 6.
I expect that this section is a little too minimal to get past the Security ADs.  I would suggest a few more words, of the form:
"""
Aside from the resonance concerns discussed in Section 3.5.3, this mechanism does not introduce any security concerns beyond the general overload-control security issues discussed in [draft-ietf-soc-overload-control-15].  Methods to mitigate the risk of resonance are discussed in Section 3.5.3.
"""

MINOR / EDITORIAL:
Section 3.2.
It would be very helpful if you could include a brief example Via header at the end of this section, showing how the oc-algo and oc parameters are set to indicate a particular level of rate control.
Section 3.4. "is the client responsibility" -> "is the client's responsibility"
Section 3.5.1. "negotiated independently" -> "negotiated out of band"
"Independently" suggests (to me) that the client and and server do it independently of one another.
Section 3.5.1. "any other equivalent algorithm" -> "any other algorithm meeting the upper bound of 1/T messages per second"
Also, this seems redundant with the previous paragraph.  Can one of them be deleted?
Section 3.5.1. "Servers with a very large number of clients..."
It seems odd for this paragraph to be written in terms of server benefit, since clients are the ones that choose TAU values.  Rephrase as guidance to clients, or optionally what the server might tell clients if there's an out-of-band way for them to configure this?