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

[Klaus Hartke <[e-mail]>]

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


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