Subject: [core] "Too Many Requests Response Code for CoAP" draft (draft-keranen-core-too-many-reqs-00)

From: Ari Keränen <[email-masked]>
Date: Mon, 5 Mar 2018 14:52:03 +0000

Hi all,

I submitted a new draft about the "Too Many Requests" CoAP Response Code (see details below). This was part of the CoAP pub/sub draft before, but as discussed in the previous meeting, there's also more wider use for this response code so it makes sense to have a separate draft about it.

While thinking about the details, I did realize that we may want to also define ways for the server to indicate what kind of requests are OK, or not OK. However, that topic may also be applicable beyond this Response Code so I didn't yet put any details here, just TBD markers. Perhaps that's also something to discuss at the London meeting.

Cheers,
Ari

> A new version of I-D, draft-keranen-core-too-many-reqs-00.txt
> has been successfully submitted by Ari Keranen and posted to the
> IETF repository.
> 
> Name:		draft-keranen-core-too-many-reqs
> Revision:	00
> Title:		Too Many Requests Response Code for the Constrained Application Protocol
> Document date:	2018-03-05
> Group:		Individual Submission
> Pages:		4
> URL:            https://www.ietf.org/internet-drafts/draft-keranen-core-too-many-reqs-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-keranen-core-too-many-reqs/
> Htmlized:       https://tools.ietf.org/html/draft-keranen-core-too-many-reqs-00
> Htmlized:       https://datatracker.ietf.org/doc/html/draft-keranen-core-too-many-reqs-00
> 
> 
> Abstract:
>   A Constrained Application Protocol (CoAP) server can experience
>   temporary overload because one or more clients are sending requests
>   to the server at a higher rate than the server is capable or willing
>   to handle.  This document defines a new CoAP Response Code for a
>   server to indicate that a client should reduce the rate of requests.
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
>

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 5 Mar 2018 17:22:57 +0100

Hi Ari,

> TBD: If a server chooses to (not)accept a request based on the
> method/resource, how should this be indicated in the reply?
>
> TBD: what kind of requests are (not) OK during the Max-Age?  For
> example: the client MAY send a different request, in particular if
> the expected load for the server is smaller with that request?

I guess the response code could be used in a number of ways, e.g.:

A:
    1. if not resource exists: return 4.04
    2. if too many requests: return 4.29
    3. if not method supported: return 4.05
    4. process request

B:
    1. if not resource exists: return 4.04
    2. if not method supported: return 4.05
    3. if too many requests: return 4.29
    4. process request

C:
    1. if too many requests: return 4.29
    2. if not resource exists: return 4.04
    3. if not method supported: return 4.05
    4. process request

'A' seems to make sense if the request rate is limited per
client/resource pair; 'B' if the request rate is limited per
client/resource/method triple; and 'C' if the request rate is limited
per client only.

Is it important that a client can distinguish between these three modes?

Should all of them be supported or would it be ok to mandate one of them?

RFC 6585 seems to leave all details to implementations.

Quick, pedantic review of KEYWORDS:

>   If a CoAP server is unable to serve a client that is sending CoAP
>   request messages more often than the server is capable or willing to
>   handle, the server SHOULD respond to the request(s) with the Response
>   Code 4.29, "Too Many Requests".

This "SHOULD" is hard to satisfy since not all implementers might be
aware that this response code exists.

--> "A server MAY return a 4.29 (Too Many Requests) response if a CoAP
client request messages more often than the server is capable or
willing to handle."

>   The server MAY include in the
>   response a Max-Age option indicating the number of seconds after
>   which the server assumes it is OK for the client to retry the
>   request.

Thou shalt not make normative statements that repeat or contradict RFC 7252.

Every 4.xx response has a Max-Age option (which may be efficiently
encoded with 0 bytes if the value equals the default value, but is
technically still there).

--> "The Max-Age Option is used to indicate the number of seconds
after which to retry."

>   If a client receives the 4.29 Response Code from a CoAP server to a
>   request, it SHOULD NOT send the same request to the server before the
>   time indicated in the Max-Age option has passed.

Not sure if this can be required. It's more like the client is
encouraged to not retry before Max-Age expires.

>   If the response
>   does not contain Max-Age option, the client SHOULD wait for the Max-
>   Age default value, 60 seconds.

Thou shalt not make normative statements that repeat or contradict RFC 7252.

The default value of 60 seconds is already specified.

Review summary: Ready for WG adoption. (Are there any other proposed
CoAP codes that could be merged into this document to streamline
registration?)

Klaus

---

From: Michael Koster <[email-masked]>
Date: Mon, 5 Mar 2018 09:39:10 -0800

We are proposing a code in Pub/Sub for the case of a broker where the topic exists but there is not a valid data value. We may be able to use an empty representation as we have decided to do with empty link collections but I fear we need more generality than depending on a special representation value to indicae no data.

We thought that an equivalent to the HTTP 204 "No Content" could be used but the code conflicts with 2.04 in CoAP, so we propose 2.07

https://datatracker.ietf.org/doc/draft-ietf-core-coap-pubsub/ <https://datatracker.ietf.org/doc/draft-ietf-core-coap-pubsub/>

Not sure if it makes sense to combine them at this time, but it might.

Best regards,

MIchael

> On Mar 5, 2018, at 8:22 AM, Klaus Hartke <[email-masked]> wrote:
>

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 5 Mar 2018 18:51:54 +0100

Michael Koster wrote:
> We are proposing a code in Pub/Sub for the case of a broker where the topic
> exists but there is not a valid data value.

This sounds strangely familiar:
https://tools.ietf.org/html/draft-hartke-core-pending-02

> We thought that an equivalent to the HTTP 204 "No Content" could be used but
> the code conflicts with 2.04 in CoAP, so we propose 2.07

We had that in the -01 version of the draft, but that didn't seem to
gain traction, so we've switched to a new content-format to indicate
this status. Would this work for pub/sub?

Klaus

---

From: Ari Keränen <[email-masked]>
Date: Thu, 8 Mar 2018 12:42:41 +0000

Hi Klaus,

Thank you for the review comments! See inline.

> On 5 Mar 2018, at 18.22, Klaus Hartke <[email-masked]> wrote:
> 
> Hi Ari,
> 

I guess it depends on the use case and how much logic we would have in the client. For many cases just backing-off is probably enough. But for example for a case where shooting measurement data at high speed is causing overload but updating RD registration would be fine, making a difference between C and A&B could be useful.

> Should all of them be supported or would it be ok to mandate one of them?

Probably quite use case dependent so not sure how much we can mandate here.

> RFC 6585 seems to leave all details to implementations.

Indeed; not much guidance there.

> client request messages more often than the server is capable or

The SHOULD of course only applies to who ever has implemented this spec. The main case I had in mind where this SHOULD would not be followed is the potential DoS case described in the security section.

> --> "The Max-Age Option is used to indicate the number of seconds

Good point. Will fix in the next version.

> encouraged to not retry before Max-Age expires.

Do you mean it can't be required for implementations that don't understand the code or in general?

> The default value of 60 seconds is already specified.

Good point; will fix too (I actually copied the 60 seconds from 7252, but you have a valid point about not repeating normative text).

> CoAP codes that could be merged into this document to streamline

Thanks!

Michael pointed out the other one that we may want to consider; let's continue the discussion in that part of the thread.

Cheers,
Ari

---

From: Ari Keränen <[email-masked]>
Date: Thu, 8 Mar 2018 13:05:22 +0000

> On 5 Mar 2018, at 19.51, Klaus Hartke <[email-masked]> wrote:
> 
> Michael Koster wrote:

The 2.05 "Content Pending" has indeed quite similar semantics to our proposal and should work for pub/sub too.

But the dual use of the "X" vs. "X pending" was a bit unclear in the draft now. Maybe it's worth clarifying already in the intro that it's the new payload format that indicates this difference. Could also mention explicitly that these are not new Response Codes, since that's probably what most readers would expect this  draft to specify.

> this status. Would this work for pub/sub?

Do you remember what was the reason for lack of traction? 

Implementation-wise it seems slightly simpler to handle different "error/pending" cases just by looking at the response code and not having to bother about the payload type, but I don't have a strong opinion on this (or an implementation, at least yet).

Cheers,
Ari

---

From: Klaus Hartke <[email-masked]>
Date: Sun, 11 Mar 2018 11:08:01 +0100

> I guess it depends on the use case and how much logic we would have in the client. For many cases just backing-off is probably enough. But for example for a case where shooting measurement data at…

What about using 5.03 for C and 4.29 for A?

It's perfectly fine that a server tells one client it's overloaded
while continuing to serve other clients.

Alternatively: Define a content-format that provides more detailed information.

> The SHOULD of course only applies to who ever has implemented this spec.

Right. It therefore sounds a bit like: "You MAY implement the spec. If
you decide to implement the spec, you SHOULD implement the spec."
That's weird :-)

> Do you mean it can't be required for implementations that don't understand the code or in general?

In general, judging by the (lack of) use of KEYWORDS in [1] and [2].

Klaus

[1] https://tools.ietf.org/html/rfc7252#section-5.9.3.4
[2] https://tools.ietf.org/html/rfc6585#section-4

---

From: Klaus Hartke <[email-masked]>
Date: Sun, 11 Mar 2018 11:14:33 +0100

Ari Keränen wrote:
> But the dual use of the "X" vs. "X pending" was a bit unclear in the draft now.

Agreed; the wording in the draft has some room for improvement.

> Do you remember what was the reason for lack of traction?

Not sure since I wasn't at IETF 100 where it was discussed. But there
are some notes in the meeting minutes [1].

Klaus

[1] https://datatracker.ietf.org/meeting/100/materials/minutes-100-core.md
(search for "13:35")

---

From: peter van der Stok <[email-masked]>
Date: Mon, 12 Mar 2018 08:48:26 +0100

> are some notes in the meeting minutes [1].
I was at ietf100, presenting the pending draft.
In short, a new response code was not encouraged; so the suggested 2.06 
was out.
Response code 5.03 (service unavailable) was suggested by Carsten, but 
we are clearly not talking about an unavailable service:
the service is available but slow.........

Not seeing any other obvious response code, Klaus suggested the 
content-format option.

Cheerio,

peter