[sip-overload] AD review: draft-ietf-soc-overload-control-13 (MINOR ISSUES)

["Vijay K. Gurbani" <[e-mail]>]

Dear Richard: Continuing from your review of the draft [0], here are the
resolutions to the minor issues.

 > 1. The last paragraph of Section 2 is tautological.  ("The normative
 > statements...this specification.")  If an entity doesn't support this
 > specification, then of course the normative requirements don't apply!
 > Do you mean something different from that?

I always liked the T-shirt that said,
     "Dept. of Redundancy Department" :-)

But all kidding aside, this was something the WG grappled with to some
extent.  The issue is that before the introduction of that paragraph,
the document was peppered with qualifying phrases such as "A SIP entity
that supports this specification..."  Ergo, to get rid of such
qualifiers, we added a blanket statement that you point out.

It appears that what we did does not quite convey the semantic we wanted
to.  I am happy to entertain other thoughts on how to not burden the
draft with the qualifying phrase.

 > 2. In Section 4.2, it would help if you could say briefly why multiple
 > algorithms are needed.  Are some algorithms better suited to different
 > overload conditions?  Or could the group just not make up its mind?
 > (Maybe there's a reference for this?)

The design team that preceded this work studied 3 different algorithms
for throttling --- rate-based, loss-based and window-based (c.f. Section
9 of RFC6357 [1]).  As the work progressed, there was strong interest
in the working group to support at least loss-based and rate-based
throttling algorithms.  The general view was that rate-based algorithms
were useful in managed networks while loss-based were productive in more
heterogeneous environments.  There was a community supporting
both the rate-based and loss-based algorithms, which is reflected as
a framework in the current draft to support multiple algorithms.

I could put a reference to S9 of RFC6357 [1] in S4.2 to signify that
multiple algorithms need to be supported.  Would that work?

 > 3. Mandating that "loss" be included in the list of supported
 > algorithms seems duplicative.  Clients are already required to
 > support "loss" and put supported algorithms in the list.  It also
 > seems undesirable for servers to rely on "loss" being present, since
 > that could cause problems if for some reason we decide to deprecate
 > "loss" in the future (cf. [[ SDP codec change ]])

I think the important issue here is that "loss" and "rate" are not
instances of particular algorithms, they are a general collection of
algorithms; to stretch an analogy, in OO terms, they are abstract classes.

An implementation can use any specific loss- or rate-based algorithm as
long as the algorithm trims the amount of traffic it promises to.
Consequently, the reference algorithm in S6.3 may be used by a simple
implementation for a loss-based scheme, but any equivalent algorithm
that reduces traffic in the same amount can be used by the client.  The
server simply expects that there will be a reduction in traffic in the
amount it indicated.  How the client accomplishes this is left to the
client.

As such, I am not too worried about the deprecation qualities of the
tokens used in the "oc-algo" parameter.

 > 4. It's not clear why the "oc-seq" parameter needs a fractional
 > portion.  Wouldn't it be simple just to make it an integer?

In case the server issues multiple responses in the same second it helps
to have a fractional portion.

 > 5. In Section 5.8, "frequent changes of overload control algorithm
 > MUST be avoided" -- This is not an RFC 2119 MUST.

Got it, will downgrade.

 > 6. In Section 5.8, "the algorithm MUST remain in effect" -> "the
 > server SHOULD NOT change the algorithm for that client"  It seems
 > like you wouldn't want to prevent the server from changing if it
 > really needed to.

Sure, I will make that change.

 > 7. In Section 5.10.2, the recommendation at the end seems a little
 > light, and unclear how to implement.  You might recommend a simple
 > algorithm to apply here, e.g., just drop everything from
 > non-supporting clients.

I have a hard time personally sating that the SIP server simply drops
all requests from non-supporting clients.  What if a request from a
non-supporting client had RPH markings?  I am susceptible to the
argument that searching for RPH markings will make the overloaded
server more slow, but all the same, I remain reticent to issue a
blanket advisory to discard all requests from non-participating clients.
Hence the exhortation to reject some requests.

I am happy to entertain other thoughts on how to handle this case.

 > 8. In Section 6.1, the last two paragraphs are completely redundant
 > with the general behavior specified above.

I will take them out.

 > 9. The example in Section 6.2 is not specific to the "loss" algorithm.
 > It should be moved up to the top level.

Sure; that is reasonable.  I will see if I can make an "Examples"
section or put the example elsewhere.

 > 10. Should Section 9 be moved to an appendix?

The working group had debated removing S9 altogether, but it was
decided that we should keep it [2].  Now, to be fair, we did not
consider moving it to an appendix as much as removing it entirely.
However, since it was felt that the section added some value to the
document, it stayed.  I am happy to move it to an appendix if that
is your preference.

 > 11. In Section 10, it's not really even necessary to use TLS to
 > prevent spoofing.  In many cases just using a connection-oriented
 > protocol like TLS or WS would be sufficient.

Do you mean "TCP or WS" above?  In light of my suggestions to modify
S10 in [3], do we still need to revisit this issue?

[0] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00988.html
[1] http://tools.ietf.org/html/rfc6357#section-9
[2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00797.html
[3] http://www.ietf.org/mail-archive/web/sip-overload/current/msg01013.html

Thanks!

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [e-mail]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq