rlqs: Support percentage/ratio-based rate limit strategies
- Dominant language
- C++
- Stars
- 28.9k
- Forks
- 5.6k
- Avg merge
- 1d 22h
- Merged PRs (30d)
- 430
Description
RLQS RateLimitStrategy only supports absolute counts, not percentage/ratio-based limits
*Description*:
The Rate Limit Quota Service (RLQS) protocol expresses quota assignments via
`type.v3.RateLimitStrategy`, which currently supports only:
- `blanket_rule` (allow all / deny all)
- `requests_per_time_unit` (an absolute uint64 count per time unit)
- `token_bucket` (absolute max tokens + fill rate)
There is no way to express a quota as a percentage or ratio of some baseline
(e.g. "allow 10% of traffic to this bucket" or "shed 25% of requests"). This
would be useful for use cases like gradual rollout/ramp-up of a rate limiting
policy, proportional load shedding across buckets, or percentage-based traffic
shaping that scales automatically with incoming volume instead of requiring a
control plane to compute and continuously update absolute request-per-second
figures.
Requesting a new `RateLimitStrategy` variant (e.g. `PercentageRule` or
`ratio`) that lets the control plane express limits as a percentage/fraction
of observed request volume, similar to the existing percentage-based fault
injection / traffic shifting semantics elsewhere in Envoy (e.g.
`envoy.type.v3.FractionalPercent`).
[optional *Relevant Links*:]
> https://www.envoyproxy.io/docs/envoy/latest/api-v3/service/rate_limit_quota/v3/rlqs.proto
> https://www.envoyproxy.io/docs/envoy/latest/api-v3/type/v3/ratelimit_strategy.proto
Contributor guide
Research direction
Start by reading the RLQS protocol and strategy definitions in service/rate_limit_quota/v3/rlqs.proto and type/v3/ratelimit_strategy.proto, along with the referenced FractionalPercent semantics. Define the percentage or ratio-based RateLimitStrategy variant and its relationship to observed request volume; done means the protocol can express the requested percentage-based quota behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- cpp
- Domain
- api, backend-api-design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100