[Dime] Spencer Dawkins' Yes on draft-ietf-dime-doic-rate-control-10: (with COMMENT)

Spencer Dawkins <spencerdawkins.ietf@gmail.com> Wed, 23 January 2019 00:06 UTC

MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Spencer Dawkins <spencerdawkins.ietf@gmail.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dime-doic-rate-control@ietf.org, Lionel Morand <lionel.morand@orange.com>, dime-chairs@ietf.org, lionel.morand@orange.com, dime@ietf.org
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154820200372.13175.6427829494337126533.idtracker@ietfa.amsl.com>
Date: Tue, 22 Jan 2019 16:06:43 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dime/KFaekKSDN5hK4u-OOO5oBR5PRuc>
Subject: [Dime] Spencer Dawkins' Yes on draft-ietf-dime-doic-rate-control-10: (with COMMENT)

Spencer Dawkins has entered the following ballot position for
draft-ietf-dime-doic-rate-control-10: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for doing this work, and for basing it on SIP Overload Control. It's
nice when protocol designers adopt good ideas from each other.

There are three SHOULDs in Section 5.1, Reporting Node Overload Control State,
I'd like to understand better.

   A reporting node that uses the rate abatement algorithm SHOULD
   maintain reporting node Overload Control State (OCS) for each
   reacting node to which it sends a rate Overload Report (OLR).

^^ This one - I'm guessing that this is "SHOULD unless you're still writing
code upgrading an implementation that treats all reacting nodes the same way",
based on this next sentence, but I'm guessing. Why wouldn't you do this?

      This is different from the behavior defined in [RFC7683] where a
      single loss percentage sent to all reacting nodes.

   A reporting node SHOULD maintain OCS entries when using the rate
   abatement algorithm per supported Diameter application, per targeted
   reacting node and per report type.

^^ Your answer to my previous question is likely to help me understand this
one, but I'm guessing reasons why you wouldn't do this.

   A rate OCS entry is identified by the tuple of Application-Id, report
   type and DiameterIdentity of the target of the rate OLR.

   The rate OCS entry SHOULD include the rate allocated to the reacting
   note.

^^ I'm really interested on this one - does the rate abatement algorithm work
without knowing the rate that's allocated? but assuming that it does work, I'm
still guessing why you wouldn't do this.

   A reporting node that has selected the rate overload abatement
   algorithm MUST indicate the rate requested to be applied by DOIC
   reacting nodes in the OC-Maximum-Rate AVP included in the OC-OLR AVP.

   All other elements for the OCS defined in [RFC7683] and
   [I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS
   when using the rate abatement algorithm.

[Dime] Spencer Dawkins' Yes on draft-ietf-dime-do… Spencer Dawkins
Re: [Dime] Spencer Dawkins' Yes on draft-ietf-dim… Steve Donovan