[sip-overload] Review of draft-ietf-soc-overload-rate-control-07.txt

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

Eric, Philip: I was asked by the chairs to review draft-ietf-soc-
overload-rate-control-07.txt.

Here are my comments, in document order.  Generally, the draft is
well written; some of the comments below may be helpful.

- S1, fourth paragraph: The rate-control draft is not as much an
  extension to draft-ietf-soc-overload-control as much as it is
  a specification for an alternative overload control mechanism.
  As such, probably best to state that "This document proposes an
  alternative, rate-based overload control algorithm within the
  framework defined in [draft-ietf-soc-overload-control-15].  The
  rate-based control algorithm guarantees an upper bound ..."

- S1, fourth paragraph, last sentence: s/loss approach./loss-based
  approach./

- S3.2: I am not sure what is the implication of the last paragraph.
  I suspect a value in the oc parameter that triggers overload control
  at the client informs the client of "overload state".  Why this
  overload state occurred (i.e., what resources are being exhausted by
  the server) is rather immaterial at the client, no?

- S3.3, first paragraph: s/string "rate"/token "rate"/
  (in 2 places)

- S3.4, sixth paragraph: "... at a rate below its target SIP request
  rate..."  Here, "its" refers to client? or server?  I think it is the
  client, but some clarification would be good.

- S3.5.2: the fact that the client maintains two categories of requests,
  one subject to reduction and the other not, is an artifact of the
  loss-based algorithm in [draft-ietf-soc-overload-control-15].  Thus, I
  don't think that this is a requirement of [draft-ietf-soc-overload-
  control-15] as much as an artifact of how the loss-based algorithm
  works.

  That said, almost any client will automatically gravitate towards two
  similar categories.  Thus it is best to specify the opening sentence of
  S3.5.2 as follows:

     As with the loss-based algorithm of [draft-ietf-soc-overload-
     control-15], a client implementing the rate-based algorithm also
     prioritizes messages into two categories of requests: ...

- S4: In the SIP messages of the example, there appear to be spurious
  new lines between header elements.  Plus, when a continuation appears
  on a new line in SIP, the first token of the new line has a LWS.  Thus,
  the Via line in the INVITE is best written as:

    Via: SIP/2.0/TLS p1.example.net;
      branch=z9hG4bK2d4790.1;received=192.0.2.111;
      oc;oc-algo="loss,rate"

  and similarly for the response.

- S6: I suspect that this draft can refer to the Security Considerations
  section of [draft-ietf-soc-overload-control-15] by reference instead of
  by value (so to speak).

  Of more interest would be a discussion of threats specific to the rate-
  based algorithm (if there aren't any, or if all such threats are
  subsumed by the discussion in [draft-ietf-soc-overload-control-15],
  then simply say so).

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