Subject: [core] 🔔 WGLC of draft-ietf-core-too-many-reqs-02

From: Carsten Bormann <[email-masked]>
Date: Mon, 2 Jul 2018 15:53:57 +0200

Dear CoRE WG,

during the London IETF, we said we want to quickly finish the spec of the response code 4.29 (too many requests).
The author has now submitted a revised version dealing with the recent comments and believes it is ready for Working Group last call.

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

The WGLC will end in exactly 336 hours so we can discuss the outcome at the CoRE WG meeting 

Grüße, Carsten

PS.: A bonus for the first one who finds the one malformed sentence I found during chair review: 
You’ll get some Finnish Salmiakki at the Montreal meeting.

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 2 Jul 2018 16:01:28 +0200

> You’ll get some Finnish Salmiakki at the Montreal meeting.

This one?

   While a 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.

:-)

---

From: Jim Schaad <[email-masked]>
Date: Thu, 5 Jul 2018 06:15:36 -0700

The draft looks fine to me.

The server gets to have a definition of what it means for something to be "too similar" for a request and there is no way for this standard to be communicated to the client.  Thus the client's idea that similar means 'the same payload' may not be the servers idea of 'any payload'.  I don't know how to fix this so I expect it to be ignored.

The document appears to say that this response code is for dealing with a single client.  That is the traffic metric is calculated individually for each client.  The proxy for each client presumably being source IP, port pair.  If the traffic metric is calculated for everybody then it should return 5.03.  If that is not the intent then this needs to be made clearer.

Note that a client could get this as a response even on its first request if the path to the server goes through a proxy agent.

Jim

> -----Original Message-----
> From: core <[email-masked]> On Behalf Of Carsten Bormann
> Sent: Monday, July 2, 2018 6:54 AM
> To: Core <[email-masked]>
> Subject: [core] 🔔 WGLC of draft-ietf-core-too-many-reqs-02
> 
> Dear CoRE WG,
> 
> The author has now submitted a revised version dealing with the recent
> comments and believes it is ready for Working Group last call.
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 5 Jul 2018 18:38:42 +0200

> Note that a client could get this as a response even on its first request if the path to the server goes through a proxy agent.

Which strikes me as moderately appropriate — after all, the client is “part of the problem”.

Grüße, Carsten

---

From: Jim Schaad <[email-masked]>
Date: Thu, 5 Jul 2018 09:48:38 -0700

> From: Carsten Bormann <[email-masked]>
> Sent: Thursday, July 5, 2018 9:39 AM
> To: Jim Schaad <[email-masked]>
> Cc: Core <[email-masked]>
> Subject: Re: [core] 🔔 WGLC of draft-ietf-core-too-many-reqs-02
> 
> > Note that a client could get this as a response even on its first request if the
> path to the server goes through a proxy agent.
> 

I understand this, however it means that a client might get this response even though it had never sent a message to the server before.  This might be considered to be unexpected behavior.

Jim

---

From: Ari Keränen <[email-masked]>
Date: Tue, 10 Jul 2018 09:10:37 +0000

Thank you for the review Jim!

Please see inline.

> On 5 Jul 2018, at 16.15, Jim Schaad <[email-masked]> wrote:
> 

While there is no good way to communicate that in generic fashion, and trying to design one here sounds a bit overkill, the “standard for similarity” can be part of the application. Hence client can have context information what is similar and what is not. And can eventually figure out from server’s reply that a request it sent was considered similar.

The other alternative would be to define here explicitly and exclusively what is similar but that would restrict the use cases.

> The document appears to say that this response code is for dealing with a single client.  That is the traffic metric is calculated individually for each client.  The proxy for each client presumabl…

If the server is able to use other information (e.g., security credentials / cookies of some sort) to make a separation per client, that could be used even via proxy. 

I guess a key difference to 5.03 besides being per client, is that too-many-reqs is also per “similar requests / request type” whereas 5.03 implies that any request would be rejected. Does that make sense? 

> Note that a client could get this as a response even on its first request if the path to the server goes through a proxy agent.

Indeed. We could add a note about that to make it less unexpected.

Cheers,
Ari

---

From: Michael Koster <[email-masked]>
Date: Tue, 10 Jul 2018 07:01:04 -0700

Hi,

I think it's out of scope for this draft to specify *how* the server determines there are too many requests, and similar related concerns.

The 4xx code indicates that the client can do something about it, and the proxy would indeed be a more confusing case. Surely there are other cases where the proxy needs to have a defined behavior in the face of things that can be retried. At least 4xx gives the proxy a chance to do something reasonable.

For example, the server could keep a ranking of the request rate from different clients and sending the TMR code preferentially to the higher ranking clients. But that may not be appropriate for all situations.

We want to keep the scope of the meaning of the code to be narrow, I think.

Best regrds,

Michael

> On Jul 10, 2018, at 2:10 AM, Ari Keränen <[email-masked]> wrote:
> 
>> On 5 Jul 2018, at 16.15, Jim Schaad <[email-masked] <mailto:[email-masked]>> wrote:
>> 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core>