Subject: [core] Ben Campbell's No Objection on draft-ietf-core-too-many-reqs-05: (with COMMENT)

From: Ben Campbell <[email-masked]>
Date: Tue, 23 Oct 2018 15:07:42 -0700

Ben Campbell has entered the following ballot position for
draft-ietf-core-too-many-reqs-05: No Objection

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-core-too-many-reqs/

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

Hi, thanks for the work on this. I have a few comments, below:

I share Adam's concern about overloading Max-Age for this purpose. If anything,
the use in this document is specifying a minimum time interval, not a maximum
one. That is, this use not only overloads Max-Age, but does it in a
counter-intuitive way. Is there a reason not to define a new option?

§4: "A client MUST NOT rely on a server being able to send the 4.29
Response Code in an overload situation because an overloaded server
may not be able to reply at all to some requests."

Can you elaborate on the practical effect of that MUST NOT?

---

From: Ari Keränen <[email-masked]>
Date: Wed, 24 Oct 2018 06:48:27 +0000

Thank you for the review Ben!

See comments inline.

> On 24 Oct 2018, at 1.08, Ben Campbell <[email-masked]> wrote:
> 
[...]

This way to use Max-Age is aligned with the 5.03 code’s use of the option. For details, see my answer to Adam’s e-mail and clarifications in the PR:
https://github.com/core-wg/too-many-reqs/pull/5/files

Personally I would not object to define a new option for this use, but since 5.03 use of Max-Age is actually quite similar, re-using that seemed to make sense.

> Can you elaborate on the practical effect of that MUST NOT?

Client should not make assumptions, e.g., that it can safely keep increasing the request rate until it receives 4.29, even if a server supports that.

Cheers,
Ari

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Oct 2018 12:37:19 -0500

Thanks for your response. Comments inline:

Thanks!

Ben.

> On Oct 24, 2018, at 1:48 AM, Ari Keränen <[email-masked]> wrote:
> 
> On 24 Oct 2018, at 1.08, Ben Campbell <[email-masked] <mailto:[email-masked]>> wrote:
> 
> https://github.com/core-wg/too-many-reqs/pull/5/files <https://github.com/core-wg/too-many-reqs/pull/5/files>
> 

I will defer to the results the discussion resulting from Adam’s comment.

> Client should not make assumptions, e.g., that it can safely keep increasing the request rate until it receives 4.29, even if a server supports that.

That seems kind of vague for a normative MUST NOT. How did clients pace requests prior to this? Are we asking them to do something different

---

From: Ari Keränen <[email-masked]>
Date: Thu, 1 Nov 2018 00:50:13 +0000

Hi Ben,

(Clipping out all except the remaining comment; see below)

> On 24 Oct 2018, at 20.37, Ben Campbell <[email-masked]> wrote:
[...]
> That seems kind of vague for a normative MUST NOT. How did clients pace requests prior to this? Are we asking them to do something different

Basic CoAP implementations using default values would have just a single request on fly, but more advanced implementation could have more e.g., based on RTT estimates. The key point here is that this error code should not be used to probe a limit the server can handle. So it’s not really any new behavior this draft is asking for, rather a hint that this code should *not* be used for this (probing) kind of “new behavior”.

What would you recommend instead of MUST NOT here? Would “should not” be more appropriate? 

Cheers,
Ari