Subject: Re: [Dime] AD Evaluation of draft-ietf-dime-doic-rate-control-10

From: Ben Campbell <[email-masked]>
Date: Wed, 16 Jan 2019 12:09:17 -0600

Hi,

IETF Last Call ends today, and unless I missed something there has been no comments that require changes beyond those I made below. However, IDNits also complains about the reference in the abstract. Normally the RFC editor prefers to have no references in the abstract. Fixing this would mean simply removing “[RFC7683]” from the abstract.

This will probably end up on the IESG Telechat on 24 January. If you are able to make any updates this week it would be helpful. Otherwise please wait until after the telechat.

Thanks!

Ben.

> On Dec 21, 2018, at 5:06 PM, Ben Campbell <[email-masked]> wrote:
> 
> Hi,
> 
> This is my AD evaluation for draft-ietf-dime-doic-rate-control-10. I previously reviewed version 8, however since some time has passed I reviewed this version “from scratch”.
> 
> In general the draft is in good shape. I think it’s ready for IETF Last Call, which I will request shortly. Please note the last call window will be extended due to the upcoming holidays.
> 
> I have a few minor comments that can be resolved along with any last call feedback.
> 
> Thanks!
> 
> Ben.
> 
> -------------------------------------
> 
> §4, paragraphs 2 and 3: Am I correct to assume that, as new DOIC algorithms get added, nodes could support both of these and something else? If so, then in paragraph 2 I suggest s/ “ support both the loss and rate based abatement algorithms”/ "support at least the loss and rate based abatement algorithms”
> 
> ... and in paragraph 3, I suggest adding something to the effect of “... and MAY indicate support for others.”
> 
> (nit) §5.5, 2nd paragraph: "It is also possible for the reporting node to send overload
> reports with the rate algorithm indicated when the reporting node
> is not in an overloaded state.”
> 
> I suggest s/ “indicated when” / “indicated even when”
> 
> (nit) §5.6, first paragraph: The algorithm is detailed in 7.3.
> 
> §7.3.1: "To apply abatement treatment to new Diameter requests at the rate
> specified in the OC-Maximum-Rate AVP value sent by the reporting node
> to its reacting nodes, the reacting node 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.”
> 
> This is redundant to similar normative text in §5.6. I suggest keeping just one (probably this one since it’s more precise) and use descriptive language for the other.
> 
> §9: Do the authors think that the rate algorithm might be more effective at DoS mitigation than the loss algorithm? If so, that might be worth a mention in the security considerations.
> 
>

---

From: Steve Donovan <[email-masked]>
Date: Thu, 24 Jan 2019 17:07:28 -0600

Ben,

I've updated the document based on our comments.  See more below.

Steve

> I have a few minor comments that can be resolved along with any last call feedback.
SRD> No, only loss is required to be supported.  The statement is that,
because loss is always required, supporting rate implies supporting loss
and rate.  I don't think a change is required here.
>
> .... and in paragraph 3, I suggest adding something to the effect of “... and MAY indicate support for others.”
SRD> I agree this is a good change.
> I suggest s/ “indicated when” / “indicated even when”
SRD> Okay.

> This is redundant to similar normative text in §5.6. I suggest keeping just one (probably this one since it’s more precise) and use descriptive language for the other.
SRD> Okay, I changed 5.6 to the following:

   When determining if abatement treatment should be applied to a
   request being sent to a reporting node that has selected the rate
   overload abatement algorithm, the reacting node can choose to
   use the algorithm detailed in Section 7.
> §9: Do the authors think that the rate algorithm might be more effective at DoS mitigation than the loss algorithm? If so, that might be worth a mention in the security considerations.
SRD> Good suggestion.  I've added the following paragraph to the
security section:

   In addition, the rate algorithm could be used to handle DoS attacks
more effectively than the loss algorithm.
>
>
>
>
> _______________________________________________
> DiME mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dime

---

From: Ben Campbell <[email-masked]>
Date: Tue, 29 Jan 2019 15:34:15 -0600

That all looks good, thanks!

Ben.

> On Jan 24, 2019, at 5:07 PM, Steve Donovan <[email-masked]> wrote:
> 
> Ben,
> 
> SRD> No, only loss is required to be supported.  The statement is that, because loss is always required, supporting rate implies supporting loss and rate.  I don't think a change is required here.
>> 
>> ..... and in paragraph 3, I suggest adding something to the effect of “... and MAY indicate support for others.”
> SRD> Good suggestion.  I've added the following paragraph to the security section:
> 
>    In addition, the rate algorithm could be used to handle DoS attacks more effectively than the loss algorithm.
>> 
>> 
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/dime <https://www.ietf.org/mailman/listinfo/dime>
>