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

Ari Keränen <> Thu, 08 March 2018 12:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9ACDF126CE8 for <>; Thu, 8 Mar 2018 04:42:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WHm8Al1XWadV for <>; Thu, 8 Mar 2018 04:42:46 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4CC02126CD6 for <>; Thu, 8 Mar 2018 04:42:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailgw201801; c=relaxed/simple; q=dns/txt;; t=1520512964; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=XNsYp38XHFZ2E0abULczX/TktEjxyZbeSAGMEaz1JF8=; b=PnUZhQQwYJGktv9Nqx1eA03XksJqjL4dfrAhuheBg2XZiNxwmMl7WO+QzWa3V99s c0nRywjlrSXaKHRfkD8M9uyDs60rOt14vtUNP4OC3FwMGDyUIRu6dpfTpx0r9dmB mT91R2jTeCnCN2DzBdM8juiSRb6xKNnv811P5kg9PjU=;
X-AuditID: c1b4fb2d-87c029c000005540-ee-5aa12fc4a91b
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id DD.FC.21824.4CF21AA5; Thu, 8 Mar 2018 13:42:44 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0352.000; Thu, 8 Mar 2018 13:42:41 +0100
From: =?utf-8?B?QXJpIEtlcsOkbmVu?= <>
To: Klaus Hartke <>
CC: core <>
Thread-Topic: [core] "Too Many Requests Response Code for CoAP" draft (draft-keranen-core-too-many-reqs-00)
Thread-Index: AQHTtJGG4yfbagWGT0GjW2g7xPGgz6PBwoqAgAR5dIA=
Date: Thu, 8 Mar 2018 12:42:41 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-ID: <>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprMIsWRmVeSWpSXmKPExsUyM2K7tO4R/YVRBvNuCVvse7ue2eLN/ttM DkweS5b8ZPJ48aGdMYApissmJTUnsyy1SN8ugSujY8VH5oIP7hVnTv5naWBsceti5OSQEDCR uPb7MFMXIxeHkMBhRolZs9exQziLGCW2N0xkBKliE7CVeNK6jxXEFhHQkDg8/SYLiM0sICFx duVhsLiwQI5E672vLBA1uRJPe2ZA2VYSnS3/mEFsFgEViUl/+4AWcHDwCthL/HlnALHrNKPE zemTwOZwCgRKXL89B2wvo4CYxPdTa5ggdolL3HoynwniagGJJXvOM0PYohIvH/9jhbDlJWac vcUEMp9ZQFNi/S59iFZriXc3TzND2IoSU7ofsoPYvAKCEidnPmGZwCg2C8mGWQjds5B0z0LS PQtJ9wJG1lWMosWpxcW56UbGeqlFmcnFxfl5enmpJZsYgVF1cMtv3R2Mq187HmIU4GBU4uGd oLcwSog1say4MvcQowQHs5IIbwAwJoV4UxIrq1KL8uOLSnNSiw8xSnOwKInznvTkjRISSE8s Sc1OTS1ILYLJMnFwSjUwLtxlbOLo8/GMP5/Ig/aQp/OuzVBWjoh6mn5qulJJneDmpxMWTPsZ HOn02sq4hmmOdK+0X3XQJPvTelFyRUuXP5OJWe83tfb2BvcVr9lTj07y/pgl41iZl5KRpmKg en1/xTtulz7Lj7w1l8N+6jw6/lgthH3RNqM/bcllLzNeXqlqmCBZsOWoEktxRqKhFnNRcSIA rDVWzaYCAAA=
Archived-At: <>
Subject: Re: [core] "Too Many Requests Response Code for CoAP" draft (draft-keranen-core-too-many-reqs-00)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 08 Mar 2018 12:42:49 -0000

Hi Klaus,

Thank you for the review comments! See inline.

> On 5 Mar 2018, at 18.22, Klaus Hartke <>; 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?)


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


> Klaus
> On 5 March 2018 at 15:52, Ari Keränen <>; 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:  
>>> Status:
>>> Htmlized:
>>> Htmlized:
>>> 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
>>> The IETF Secretariat