Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Post-request Reporting of hits_addend #636

Open
austince opened this issue Jul 1, 2024 · 6 comments
Open

Post-request Reporting of hits_addend #636

austince opened this issue Jul 1, 2024 · 6 comments
Labels

Comments

@austince
Copy link

austince commented Jul 1, 2024

When implementing general quota usage metering and limiting of I/O applications (like databases), the cost of each request is not known ahead of time. Adding the ability to report the request's usage (hits_addend) after the request has been processed would allow more flexible rate-limiting use cases such as these.

I don't know if it would make sense to modify the RLS v3 API, but could essentially extend it in this service with:

service RateLimitService {
  // ... other methods

  // Report Usage
  rpc ReportUsage(RateLimitRequest) returns (RateLimitResponse) {
  }
}

Request -> Server
Server -> Rate Limit Service (ShouldRateLimit hits_addend = 0)
Server -> DB (calculate cost)
Server -> Rate Limit Service (ReportUsage hits_addend = cost)
Server -> Response based on RateLimitResponse

Using the same Request and Response objects would allow also the caller to choose whether to enforce the limit consistently or trade performance and report the usage async of sending the response.

If something like a standard header for specifying hits (envoyproxy/envoy#34184) gets added to envoy, we could also consider upstreaming this to the RLS API and supporting the same header on responses for reporting cost.

@austince
Copy link
Author

austince commented Jul 1, 2024

Actually, I don't think we need another method for this other than ShouldRateLimit(..), if it were possible to call it after the request is processed, though that would have to be an envoy proposal... will take it there if this idea makes any sense/pending feedback.

Request -> Envoy
Enovy -> Rate Limit Service (ShouldRateLimit hits_addend = 0)
Enovy -> Backend (report hits_addend in response header)
Envoy -> Rate Limit Service (ShouldRateLimit hits_addend = cost) [optionally, send after response]
Envoy -> Response

If all done in Envoy, there may be some kind of "local acceptable margin of error/overage" we could encode as well 🤔

Copy link

github-actions bot commented Aug 1, 2024

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label Aug 1, 2024
@austince
Copy link
Author

austince commented Aug 1, 2024

help wanted 🙏🏼

@github-actions github-actions bot removed the stale label Aug 2, 2024
Copy link

github-actions bot commented Sep 1, 2024

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label Sep 1, 2024
@austince
Copy link
Author

austince commented Sep 3, 2024

help wanted – is there a better place to move this question?

@github-actions github-actions bot removed the stale label Sep 3, 2024
Copy link

github-actions bot commented Oct 3, 2024

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label Oct 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant