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

[Ari Keränen <[e-mail]>]

Hi Klaus,

Thank you for the review comments! See inline.

> On 5 Mar 2018, at 18.22, Klaus Hartke <[e-mail]> wrote:
> 
> 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?

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.

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

> 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

> Klaus
> 
> 
> On 5 March 2018 at 15:52, Ari Keränen <[e-mail]> wrote:
>> 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