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

From: [email-masked]
Date: Fri, 29 Jun 2018 10:35:00 -0700

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:
https://datatracker.ietf.org/doc/draft-ietf-core-too-many-reqs/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-core-too-many-reqs-01
https://datatracker.ietf.org/doc/html/draft-ietf-core-too-many-reqs-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-core-too-many-reqs-01

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Ari Keränen <[email-masked]>
Date: Fri, 29 Jun 2018 17:41:45 +0000

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, [email-masked] wrote:
> 
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Abhijan Bhattacharyya <[email-masked]>
Date: Sat, 30 Jun 2018 01:54:56 +0530

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 https://tools.ietf.org/html/draft-bormann-t2trg-stp-00 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: [email-masked]
Website: http://www.tcs.com
____________________________________________
Experience certainty.	IT Services
Business Solutions
Consulting
____________________________________________

-----"core" <[email-masked]> wrote: -----
To: core <[email-masked]>
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

Cheers,
Ari

_______________________________________________
core mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/core
=====-----=====-----=====
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

---

From: Ari Keränen <[email-masked]>
Date: Sat, 30 Jun 2018 09:40:27 +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:
https://github.com/core-wg/too-many-reqs/pull/1/files

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.

Cheers,
Ari

> On 29 Jun 2018, at 23.24, Abhijan Bhattacharyya <[email-masked]> wrote:
> 
> Hi Ari,