Subject: [Gen-art] Gen-ART LC review of draft-ietf-soc-overload-control-14.txt

From: Brian E Carpenter <[email-masked]>
Date: Sun, 15 Dec 2013 11:10:32 +1300

I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at
<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-soc-overload-control-14.txt
Reviewer: Brian Carpenter
Review Date: 2013-12-15
IETF LC End Date: 2013-12-23
IESG Telechat date:

Summary:  Almost ready
--------

Comments:
---------

Note: http://datatracker.ietf.org/ipr/1364/

Minor Issues:
------------

"  The normative statements in this specification as they apply to SIP
   clients and SIP servers assume that both the SIP clients and SIP
   servers support this specification.  If, for instance, only a SIP
   client supports this specification and not the SIP server, then
   follows that the normative statements in this specification pertinent
   to the behavior of a SIP server do not apply to the server that does
   not support this specification."

I don't find the second sentence useful. A useful sentence would be
a summary of what might go wrong if one side supports this specification
and the other doesn't. (As detailed in 5.10.2 for example.)

"5.6.  Forwarding the overload control parameters

   Overload control is defined in a hop-by-hop manner.  Therefore,
   forwarding the contents of the overload control parameters is
   generally NOT RECOMMENDED and should only be performed if permitted
   by the configuration of SIP servers.  This means that a SIP proxy
   SHOULD strip the overload control parameters inserted by the client
   before proxying the request further downstream."

I think the reader should be reminded at this point that the proxy also
behaves as a client, so will immediately re-insert its own "oc" parameters.
(In fact it would be very odd if the proxy supported overload control
upstream but not downstream.)

"13.2.  Informative References"

I am not convinced that I-D.ietf-soc-overload-rate-control is correctly
classified as an Informative reference; for example see the citation
in section 5.3. It seems to me that an implementor would need to
consult the reference.

Ditto I-D.ietf-soc-load-control-event-package (section 8).

Nit:
----

I hope this is a nit: the Last Call says it's for "Internet Standard"
but surely it's intended to be "Proposed Standard"?

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 16 Dec 2013 08:36:05 -0600

Brian: Thank you for the review.  Please see inline.

On 12/14/2013 04:10 PM, Brian E Carpenter wrote:
> [...]

This blanket statement was added at the behest of the WG that preferred
such a statement in lieu of most sentences starting with "If a SIP
client supports ...".

> upstream but not downstream.)

You are right that most, if not all, proxies would support overload
control on the client and server side.  When the proxy acts as a server,
it will ask the upstream client to throttle messages if the proxy is
overloaded.  When the proxy acts as a client, it is performing
throttling for the downstream server.

However, the pedantic notion in the text you quote is that the proxy
scrubs the overload control parameters from the Via header corresponding
to the upstream client, and adds overload control parameters in the Via
header the proxy inserts in the request going further downstream.  To
make this notion clear, I can insert the following sentence as the last
sentence of the lone paragraph in S5.6:

    "Of course, the proxy can add overload control parameters pertinent
     to itself in the Via header it inserts in the request going
     downstream."

Let me know if that captures the intent of your comment.

> in section 5.3. It seems to me that an implementor would need to

So, draft-ietf-soc-overload-rate-control is an informative
reference to this draft.  This follows from the fact that draft-
ietf-soc-overload-control defines a framework where different classes
of overload control algorithms could be plugged in.  Performing
overload control by using a rate-based algorithm is one such example.
Implementors of draft-ietf-soc-overload-control only implement the
loss-based traffic reduction algorithm, but the text exhorts them to
play better with other class of algorithms by pointing out that other
traffic reduction schemes may be used as well.

Your comment above actually triggered me to ensure that draft-ietf-soc-
overload-rate-control has a normative dependency on draft-ietf-soc-
overload-control.  It does not.  I will inform the author of the rate-
control draft.

> Ditto I-D.ietf-soc-load-control-event-package (section 8).

Ditto as above.

> but surely it's intended to be "Proposed Standard"?

Oh gosh, yes, indeed.  It is supposed to be a PS.

Thanks for your time, Brian.  I appreciate your comments.

Cheers,

- 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} / [email-masked]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 17 Dec 2013 14:21:40 +1300

Hi Vijay,

> such a statement in lieu of most sentences starting with "If a SIP

OK, if it is a hard-won rough consensus let it stand!

> Let me know if that captures the intent of your comment.

Exactly. (I know it is stating the obvious, but it removes any doubt
from the reader's mind.)

>> Ditto I-D.ietf-soc-load-control-event-package (section 8).

It's fine as long as you've thought about it. The official rule
is in RFC 2026: the document must 'stand as a complete and
understandable document with or without the reference to the
"Work in Progress".'

> Thanks for your time, Brian.  I appreciate your comments.

You're welcome!

   Brian

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 17 Dec 2013 07:47:16 -0600

On 12/16/2013 07:21 PM, Brian E Carpenter wrote:
[...]
> Exactly. (I know it is stating the obvious, but it removes any doubt

Brian: Sure; I will add the suggested sentence in the next revision.

[...]
> understandable document with or without the reference to the

Indeed, I believe that draft-ietf-soc-overload-control passes that
metric, the reverse is not true.  That is, the other two drafts,
namely draft-...-event-package and draft-...-rate-control need
draft-..-overload-control as a normative reference.  I will inform
the WG about it.

Thanks, Brian.

- vijay