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

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

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 <[e-mail]> 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 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:- [phone]
> Mailto: [e-mail]
> Website: http://www.tcs.com
> ____________________________________________
> Experience certainty. IT Services
> Business Solutions
> Consulting
> ____________________________________________
> 
> 
> -----"core" <[e-mail]> wrote: -----
> To: core <[e-mail]>
> 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, [e-mail] 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:
> > 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/
> > 
> > _______________________________________________
> > core mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/core
> 
> _______________________________________________
> core mailing list
> [e-mail]
> 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
> 
>