Variable Rate Limit Rules

[mfortini]

You document cases where a server may apply multiple rules and could advertise these rules in the Limit header. We have cases where we apply optional rules. We would specifically not advertise these rules in the Limit header. This could lead to wildly varying values in the Limit and Remain headers. You do touch on this but it seems like something that could be expanded on.

[ioggstream]

Could you provide more details, pls?

[V7k3ng]

It is possible as described to have multiple rate limit rules applying to an interaction. These may or may not be described in the RateLimit-Limit header. This could result in a caller getting back greatly varying responses in consecutive calls:

Call 1

RateLimit-Remaining: 1000
RateLimit-Reset: 10

Call 2

RateLimit-Remaining: 999
RateLimit-Reset: 10

Call 3

RateLimit-Remaining: 0
RateLimit-Reset: 600

It seems that this should be highlighted such that a caller is aware they should as far as possible treat every result individually and not cache or in any other way attempt to make forward looking predictions about the potential result of a subsequent call.

[unleashed]

It seems that this should be highlighted such that a caller is aware they should as far as possible treat every result individually and not cache or in any other way attempt to make forward looking predictions about the potential result of a subsequent call.

Well, computing the rate expectations from the service provider so that it keeps servicing a user agent is the main purpose of specifying this information in responses. The I-D allows a situation like the one in your third call just because the factors that drive rate limiting decisions can be multiple, varied, dynamic and not something you can or want to communicate to user agents - but that does not mean that these agents are expected to receive random values in each response, just that they should adapt to such sudden changes. Otherwise providing these fields would be next to useless.

The possibility is open for services to respond with values like in the scenario above so that clients will adapt, but we expect that a service will provide information that will be maintained for the specified time window to the best of its knowledge (perhaps this could be added for clarification) - providing wildly varying values will be counterproductive to servicing clients in the first place, and may result in them becoming very conservative until some time has elapsed with less stringent values provided in the fields before they start increasing their rates to previous levels.

Also note that while there is the possibility of new out of band data to inform the rate limiting policy in a way that you see the scenario above, you could also see similar behaviour if the third request was performed to a different endpoint of the service, ie. an endpoint with a different rate limiting policy. The scope of the returned information is not defined in this ID so a generic user agent either assumes a particular scope (ie. by service, by endpoint, by time of day, etc) or it would need to use information from multiple responses to heuristically infer a scope - in the third call above, if the target endpoint was different, I'd assume there's a different rate limiting policy - but that's what it is, just an assumption.

[ioggstream]

@unleashed do you think this issue requires some clarification in the spec?

[unleashed]

I kind of assume what I explain in my comment above from reading the text, but clearly that might fall short for other people and I might just be too biased and used to my mental framework.

Clarifying this wouldn't hurt, though I'm not sure whether this would best be served as a comment in the examples or somewhere next to the field definitions?

[ioggstream]

The final spec is not expected to contain too many considerations.

If it's not that clear, we can at most highlight that:

• the provider is the only responsible of the coherence of the returned values between different responses;
• the consumer may need to implement throttling in different ways, depending on the usage pattern (eg. multiplexing, ...)

@V7k3ng can this work for you?

[V7k3ng]

My only concern was to have a recommendation that developers of consumers should consider only the values of individual responses and not make any design choices based on expecting fixed patterns in rate limit responses. If this concern is out of scope of the spec, that is fine

[ioggstream]

@V7k3ng

consumers should consider only the values of individual responses and not make any design choices based on expecting fixed patterns in rate limit responses

This was added here: is that ok?

A client receiving RateLimit fields MUST NOT assume that subsequent responses contain the same RateLimit fields, or any RateLimit fields at all.

https://www.ietf.org/archive/id/draft-ietf-httpapi-ratelimit-headers-02.html#section-4-3

[V7k3ng]

Thanks yes, that's generic enough to cover a number of scenarios.

[ioggstream]

Thanks! I'll close then :) your feedback was very useful!