Re: [core] I-D Action: draft-ietf-core-too-many-reqs-01.txt

Ari Keränen <> Sat, 30 June 2018 09:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A57D8131053 for <>; Sat, 30 Jun 2018 02:41:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.331
X-Spam-Status: No, score=-3.331 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=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 3Cn8rkrMkXN0 for <>; Sat, 30 Jun 2018 02:41:14 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8CD5E131051 for <>; Sat, 30 Jun 2018 02:41:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailgw201801; c=relaxed/simple; q=dns/txt;; t=1530351672; 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=Jvsx3i1soLEuPDZ6H+TKyhJ7IsnzRfu7O3D6Fvevc/I=; b=JYwckOIEsmK1ZnZWMwh2XsEmia1K0bHgV3z5sUUWd8EDY2sx7SoUROAyBvy4m8IO Wgr3iA+bHF6Gu/O2CbR2YNXrggUjlJVY7DL+M/7sbBvDFxLfGZC7TL4E4bqx/akm R3gW3wu4GnNRnMj8kNZbdUeTbYv802OIpUhkFQ2qnsk=;
X-AuditID: c1b4fb3a-dcb6e9c0000079c1-82-5b375038af9c
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 9C.DF.31169.830573B5; Sat, 30 Jun 2018 11:41:12 +0200 (CEST)
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.1466.3; Sat, 30 Jun 2018 11:40:27 +0200
Received: from ([]) by ([]) with mapi id 15.01.1466.003; Sat, 30 Jun 2018 11:40:27 +0200
From: =?utf-8?B?QXJpIEtlcsOkbmVu?= <>
To: Abhijan Bhattacharyya <>, core <>
Thread-Topic: [core] I-D Action: draft-ietf-core-too-many-reqs-01.txt
Thread-Index: AQHUD8+GgeKtCIU/v0i/inkqwsFSM6R3X70AgAAtmQCAAN5EgA==
Date: Sat, 30 Jun 2018 09:40:27 +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+NgFprEIsWRmVeSWpSXmKPExsUyM2J7ma5FgHm0wfmFBhZPZu9ls9j3dj2z A5PHkiU/mTxmvJ/KGsAUxWWTkpqTWZZapG+XwJXx+/QOtoJ7nhVvPk9ha2B8497FyMkhIWAi 8XrRYdYuRi4OIYGjjBI7Z26Dcr4xSqz+uJodwlnGKLHmxHdWkBY2AVuJJ637gGwODhGBQInV r2RBwsICLhLL1nxhggi7Sjycow8SFhFwkjj1fhsbiM0ioCpx4FEDmM0rYC/x+PNtZojx+xkl Jk36DzaSUyBAYveOQpAaRgExie+n1jCB2MwC4hK3nsxngjhaQGLJnvPMELaoxMvH/1ghbCWJ vceus4CMYRbQlFi/Sx+i1Vpix+TZLBC2osSU7ofsECcISpyc+YRlAqPYLCQbZiF0z0LSPQtJ 9ywk3QsYWVcxihanFhfnphsZ6aUWZSYXF+fn6eWllmxiBMbUwS2/rXYwHnzueIhRgINRiYe3 z9o8Wog1say4MvcQowQHs5IIb2CQWbQQb0piZVVqUX58UWlOavEhRmkOFiVxXqc0iyghgfTE ktTs1NSC1CKYLBMHp1QDI4fLZL43ie+Lmit9dl/N//XmRdA/4bbAj6xX0y53P1q2+diff7/a 1nUmr/L0Z+Fe/9O749zHK5qP2H992VI658bWJRemy9z5s1zpp8nHOwJFDOJJCVv4Oo+aus89 9Tc3efqHuESDrNRpIdKmzY7cDAe9ovKfmNQVCSwVr95eeO3j3Rk+gUesziuxFGckGmoxFxUn AgDfcQpEpQIAAA==
Archived-At: <>
Subject: Re: [core] I-D Action: draft-ietf-core-too-many-reqs-01.txt
X-Mailman-Version: 2.1.26
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: Sat, 30 Jun 2018 09:41:18 -0000

Hi Abhijan, all,

I think you have a good point and making this addition to the draft makes sense to me.

One way to address this would be to redefine what we mean by same/similar requests and explicitly mention the series case. Something like this:

The key change is this new paragraph in intro:
> While server may not be able to response to a one kind of request, it
> may be able to respond to a different request, even from the same
> client. Therefore the back-off period applies only to similar
> requests. For the purpose of this document, a request is similar if it
> has the same method, Request-URI, and payload. Also if a client is
> sending a sequence of requests that are part of the same series
> (e.g., a set of measurements to be processed by the server) they are
> considered similar even if request payloads may be different.

And in client behaviour say "similar request" instead of "the same request".

Comments welcome! If something like that works for everyone, I could submit a new version with this before the draft DL.


> On 29 Jun 2018, at 23.24, Abhijan Bhattacharyya <> wrote:
> Hi Ari,
> This is indeed an useful addition. 
> I would like to bring in an aspect which may be highly related to this. Since I was not actively involved in the earlier discussions related to this draft, first hand apologies if it is a repetition.
> I would like to take clue from and think of a time-series transaction. There may be cases where the client is sending a series of information-parts to a resource in the remote server such that, the end application collects all the parts and arranges them in chronological order to continuously build the information-flow. In such a situation, every information-part may be transferred as an independent POST request by the client. Furthermore, to optimize the resource usage and satisfy throughput requirements, the client may send a significant part of these requests as NON with No-Response option (with dis-interest only in the 2.xx responses). However, this open-loop approach has a potential adverse effect in the form of blindly increasing the load on the server as well as congesting the network. This response code can be a saviour in such situations.
> However,   Section 4 of the draft says: "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." 
> The above text covers the case for usual independent sensor updates. But it exempts the situation narrated earlier. Note that, in that case the client  may not at all be interested to send the same request again. Rather, the client is sending another independent request (may be quicker than desired by the server). 
> So, can the interpretation of this response code be extended a bit so that scenarios like this may also be covered? (This indicates that probably we need a little more than the HTTP counterpart. HTTP assumes an underlying layer of TCP which handles the flow rate, congestion control and is always a closed-loop system) .
> Thank you. 
> With Best Regard.
> Abhijan Bhattacharyya
> Associate Consultant
> Scientist, TCS Research
> Tata Consultancy Services
> Building 1B,Ecospace
> Plot -  IIF/12 ,New Town, Rajarhat,
> Kolkata - 700160,West Bengal
> India
> Ph:- 033 66884691
> Cell:- +919830468972
> Mailto:
> Website:
> ____________________________________________
> Experience certainty. IT Services
> Business Solutions
> Consulting
> ____________________________________________
> -----"core" <> wrote: -----
> To: core <>
> From: Ari Keränen 
> Sent by: "core" 
> Date: 06/29/2018 11:19PM
> Subject: Re: [core] I-D Action: draft-ietf-core-too-many-reqs-01.txt
> This version adds simply a hint that a server can use action payload with error response to give client guidance how to act (as discussed at the CoRE meeting in IETF 101). Based on all feedback so far the draft seems to be ready to move forward.
> Cheers,
> Ari
> > On 29 Jun 2018, at 20.35, wrote:
> > 
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts directories.
> > This draft is a work item of the Constrained RESTful Environments WG of the IETF.
> > 
> >        Title           : Too Many Requests Response Code for the Constrained Application Protocol
> >        Author          : Ari Keranen
> > Filename        : draft-ietf-core-too-many-reqs-01.txt
> > Pages           : 4
> > Date            : 2018-06-29
> > 
> > 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.
> > 
> > 
> > The IETF datatracker status page for this draft is:
> >
> > 
> > There are also htmlized versions available at:
> >
> >
> > 
> > A diff from the previous version is available at:
> >
> > 
> > 
> > Please note that it may take a couple of minutes from the time of submission
> > until the htmlized version and diff are available at
> > 
> > Internet-Drafts are also available by anonymous FTP at:
> >
> > 
> > _______________________________________________
> > core mailing list
> >
> >
> _______________________________________________
> core mailing list
> =====-----=====-----=====
> Notice: The information contained in this e-mail
> message and/or attachments to it may contain 
> confidential or privileged information. If you are 
> not the intended recipient, any dissemination, use, 
> review, distribution, printing or copying of the 
> information contained in this e-mail message 
> and/or attachments to it are strictly prohibited. If 
> you have received this communication in error, 
> please notify us by reply e-mail or telephone and 
> immediately and permanently delete the message 
> and any attachments. Thank you