Subject: [core] Tsvart last call review of draft-ietf-core-too-many-reqs-04

From: Jana Iyengar <[email-masked]>
Date: Thu, 18 Oct 2018 17:56:50 -0700

Reviewer: Jana Iyengar
Review result: Ready with Nits

I've reviewed this document as part of the transport area review team's ongoing
effort to review key IETF documents. These comments were written primarily for
the benefit of the transport area directors. Document editors and WG chairs
should treat these comments just like any other last call comments.

This is a simple document that defines a new response code for CoAP servers to
use when under overload. The response code ("4.29 Too Many Requests") is used
as a flow control signal to indicate to a client that it needs to stop sending
more "similar" requests. The amount of time that the client needs to back off
is encoded in the response.

This is a straightforward document and I see no major issues, but I have a
couple of suggestions that might help implementers.

1. There should be text suggesting what a server MAY do if the client doesn't
respect the backoff period indicated in the response. For instance, a server
MAY drop all incoming requests from a client for an extended period of time if
the client sends a request without waiting for the duration of the backoff
period (or some such).

2. There should be some text suggesting that the server does not have to (and
probably should not) respond to every incoming request during overload with
this response. Even when the server wants to ask clients to back off, it does
not need to do that on every incoming request from a client. For instance, a
server can choose to respond to each client once in every estimated round-trip 
time.

3. Is the expectation that the client waits for the back off time starting from
when the response is received? That seems like the most obvious way to do it,
but it might be useful to clarify precisely when the client's backoff period
starts.

---

From: Ari Keränen <[email-masked]>
Date: Sun, 21 Oct 2018 18:50:31 +0000

Thank you for the review Jana!

Please see inline.

> On 19 Oct 2018, at 3.57, Jana Iyengar <[email-masked]> wrote:
> 
> Reviewer: Jana Iyengar

Simply dropping incoming requests results likely in retransmissions, which could be counter-productive for reducing load. I think the best way for the server is to answer with a different error code since if it is a well-behaving client, likely the reason for it to not respect the backoff is that it didn’t simply recognize the error code and understand what to do with Max-Age. 

I’m thinking of adding text in “CoAP server behavior” section along the lines of:

  If a client repeats a request that was answered with 4.29 before Max-Age time has passed, it is possible the client did not recognize the error code and the server MAY respond with a more generic error code (e.g., 5.03).

> server can choose to respond to each client once in every estimated round-trip 

So this would be mainly for the case when client sends multiple requests before it has a chance to receive the 4.29 to an earlier request? For that once every RTT seems indeed reasonable.

> but it might be useful to clarify precisely when the client's backoff period

RFC7252 says that Max-Age is intended to be current at the time of transmission. But since the precision of Max-Age is at the level of seconds, starting a timer when response is received sounds like a fair approximation. 

Cheers,
Ari

---

From: Ari Keränen <[email-masked]>
Date: Mon, 22 Oct 2018 21:40:54 +0000

Hi Jana et al,

I submitted now a new draft version with updates as discussed below, except for the last item, “when to start timer for back-off”. Carsten pointed out (in off-list discussion) that the issue of interpreting Max-Age time actually goes beyond the scope of this draft and should be considered for CoAP at large. Another document is planned that will clarify these aspects.

Cheers,
Ari

> On 21 Oct 2018, at 21.50, Ari Keränen <[email-masked]> wrote:
>