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

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.

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

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

Michael Koster

2018-03-05 17:39:10 UTC

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

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

Klaus Hartke

2018-03-05 17:51:54 UTC

Post by Michael Koster
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

Post by Michael Koster
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

Ari Keränen

2018-03-08 13:05:22 UTC

Post by Michael Koster
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.

https://tools.ietf.org/html/draft-hartke-core-pending-02

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.

Post by Michael Koster
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?

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

Klaus Hartke

2018-03-11 10:14:33 UTC

Post by Ari KerÃ¤nen
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.

Post by Klaus Hartke
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?

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")

peter van der Stok

2018-03-12 07:48:26 UTC

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].

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

Ari Keränen

2018-03-08 12:42:41 UTC

Hi Klaus,

Thank you for the review comments! See inline.

Post by Klaus Hartke
Hi Ari,

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
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
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?

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.

Post by Klaus Hartke
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.

Post by Klaus Hartke
RFC 6585 seems to leave all details to implementations.

Indeed; not much guidance there.

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 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 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."

Good point. Will fix in the next version.

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.

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

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.

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

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

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

Post by Klaus Hartke
Klaus

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

Klaus Hartke

2018-03-11 10:08:01 UTC

Post by Ari KerÃ¤nen
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.

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.

Post by Klaus Hartke
--> "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 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 :-)