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

From: Suresh Krishnan <[email-masked]>
Date: Wed, 24 Oct 2018 20:31:15 -0700

Suresh Krishnan 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:
----------------------------------------------------------------------

* Section 3

If the server is maintaining state per clients for the Max-Age, does the timer
get reset if a repeat request comes in before the timer expires?

* Section 4

I think it could be useful to recommend some behavior for the proxies as well,
in order to avoid a specific client being starved by other clients on a proxy.

---

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

Thank you for the review Suresh! Please see inline.

Also one question regarding proxy behavior also for the CoRE list below.

> On 25 Oct 2018, at 6.31, Suresh Krishnan <[email-masked]> wrote:
[...]

This would be up to the implementation (and deployment) to decide. For example, if it takes a constant time for the server to recover independent of the new requests, not reseting makes sense. OTOH, if even the un-served requests push back the time to recover, or the server has new information on the situation, doing an adjustment could be the right choice.

But overall keeping per-client state is not necessarily a good idea as mentioned in the draft.

> in order to avoid a specific client being starved by other clients on a proxy.

I’m not sure if the proxies can do much for this. And if they can, probably it would be something more generic than just for this response code and hence better suited for the new “clarifications and corrections” draft in CoRE.

Does anyone have good ideas what could be recommended on this?

Cheers,
Ari