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

[Michael Koster <[e-mail]>]

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 <[e-mail]> wrote:
> 
> Thank you for the review Jim!
> 
> Please see inline.
> 
>> On 5 Jul 2018, at 16.15, Jim Schaad <[e-mail] <mailto:[e-mail]>> wrote:
>> 
>> 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.
> 
> 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 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.
> 
> 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
> 
> -----Original Message-----
>>> From: core <[e-mail]> On Behalf Of Carsten Bormann
>>> Sent: Monday, July 2, 2018 6:54 AM
>>> To: Core <[e-mail]>
>>> Subject: [core] 🔔 WGLC of draft-ietf-core-too-many-reqs-02
>>> 
>>> 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.
>>> 
>>> _______________________________________________
>>> core mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/core
>> 
>> _______________________________________________
>> core mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/core
> _______________________________________________
> core mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/core <https://www.ietf.org/mailman/listinfo/core>