http: add priority_load_shed extension filter for priority-based overload shedding#45039
http: add priority_load_shed extension filter for priority-based overload shedding#45039leosarra wants to merge 23 commits into
Conversation
188e40b to
122e61d
Compare
| /*/extensions/filters/http/local_ratelimit @mattklein123 @wbpcode | ||
| /*/extensions/filters/common/local_ratelimit @mattklein123 @wbpcode | ||
| # Priority load shed | ||
| /*/extensions/filters/http/priority_load_shed @kbaichoo @botengyao |
There was a problem hiding this comment.
not sure who to put here, I added the maintainers involved in the review of the original issue (@KBaichoo @botengyao) . Let me know if I need to change this
There was a problem hiding this comment.
Hi @leosarra, have you followed Envoy extension policy prior to implementing this extension?
There was a problem hiding this comment.
Ouch, sorry I was not aware of this requirement. I will raise an issue for the proposal of this extension filter (probably it is better to not reuse the old issue) and I will check if someone is willing to sponsor it.
Then we can continue with this PR
There was a problem hiding this comment.
It took a while but proposal is up here: #45993
There was a problem hiding this comment.
looks like @KBaichoo is okay with sponsoring. cc @botengyao
ff0faeb to
70f7e3c
Compare
2084996 to
6f50d48
Compare
|
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
|
Failure in precheck looks unrelated to the changes, probably a flaky test |
6d3e244 to
c14914d
Compare
|
/lgtm api |
| // Numeric range of header values in half-open interval semantics [start, end). | ||
| type.v3.Int64Range value_range = 1; | ||
|
|
||
| // Name of the overload manager load shed point used for this bucket. | ||
| string load_shed_point = 2 [(validate.rules).string = {min_len: 1}]; |
There was a problem hiding this comment.
How much range do you think we'd need e.g. do we need full Int64Range for values?
Also how many buckets do you think would be needed? For example SRE book uses 4.
Also what happens for requests above the range?
It would also be worth documenting the direction of priority.
There was a problem hiding this comment.
On second thought, Int64Range is definitely overkill, but I do expect use cases where more than 4 buckets are defined. In the case of SBI Message Priority, the 3GPP standard defines 32 levels, in the worst case, someone could decide to assign a different threshold to each one.
Ideally I'd prefer to stay within the range 0–255. Since an unsigned 8-bit range isn't available in the proto, I've reduced it to Int32Range.
Also what happens for requests above the range?
If the priority header value exceeds the representable range, atoi will fail and a 400 status code is returned.
It would also be worth documenting the direction of priority.
The filter does not enforce any priority direction. The direction is dictated by how the user defines the buckets and their associated load shed points. I've added a comment to make this clear.
|
/wait |
Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
Change-Id: Ica10811d9194789f25368fb2b9972dad5045aadb Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
Change-Id: I66569a0d2ba12f482fdde4642dd06aa70e4e8661 Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
Change-Id: I486cc4769aac0dca67ae4aa7b5e3b78f73ae76ae Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
Change-Id: Ie58ef7f7d4e04c38550c4e0ea2088567e6656b36 Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
Change reject_on_missing_header and reject_on_invalid_header from bool to google.protobuf.BoolValue so that individual data plane implementations can decide their own defaults when the fields are unset. Change-Id: I70c4231ea197b31acb56b0d5b875b4096af7a6c0 Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
Int64Range is overkill for priority values. Switched to Int32Range which is sufficient for the 0-255 range. Updated C++ types from int64_t to int32_t accordingly. Also added documentation for priority direction convention and unmatched request behavior. Removed reject_on_missing_header and reject_on_invalid_header options in favor of simpler behavior: reject with 400 unless default_load_shed_point is configured. Change-Id: I384f71086c215b2d41cb1c8ad3212c8db7f70471 Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
Removed tests for reject_on_missing_header and reject_on_invalid_header. Updated tests to expect 400 rejection when no default_load_shed_point is configured and header is missing, invalid, or unmatched. Change-Id: I4f6428a605efa153c78ee2a751309fb1316e2618 Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
Remove unused protobuf:utility_lib dep from BUILD. Add priority_load_shed/BUILD to visibility_excludes in format config. Change-Id: If22ef75b04762cca11c77e54c337b0ca684d73c6 Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
3a9e5d8 to
268c64e
Compare
…d equivalents Change-Id: I8a448542c5080dfa3191ae01b939d690beb85ea6 Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
Use context.shouldBypassOverloadManager() directly instead of context.listenerInfo().shouldBypassOverloadManager() which is only available on ListenerFactoryContext, not FactoryContext. Change-Id: I049b20e6768a1ccfd49eb8b3ea4cd0bdca90d2cf Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
Change-Id: I2d32a967fd0f7a98bd56477b0c35fbfa5a576f94 Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
KBaichoo
left a comment
There was a problem hiding this comment.
/wait
Thank you for iterating on this, took another pass at it.
Change-Id: I9c307478c75783b5b944a65e8281c54327903dfa Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
Change-Id: I222367a1e0fde50ea02d13b583198a99ba1b2674 Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
Change-Id: I68398f78d67011c6e9f4b664bbc5f3a2b10d2113 Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
Change-Id: I26e5467ab1d8fc3e61c1135ee6b0771c402dc361 Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
Change-Id: I1616dfe74af3db148dbab720d8605bb45668f64e Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
Change-Id: I90c708cf56bba5a759dfc002e3af103fda1fb6ab Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
|
/wait Most of the changes are in place. I keep it on wait until I finish some changes to the tests and doc |
Change-Id: I2230a83746017a786200455999a6de98529c76d0 Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
Change-Id: I10ac28ef72fcf60adcdce73c243c5477862f32bb Signed-off-by: Leonardo Sarra <leonardosarra96@gmail.com>
bc32ce8 to
c826ad0
Compare
Commit Message: http: add priority_load_shed filter for priority-based overload shedding
Additional Description:
Adds a new alpha HTTP filter, envoy.filters.http.priority_load_shed, that maps a configured request header value into buckets and checks corresponding overload manager load shed points.
The filter reads a configured request header and treats its first value as the request priority. The priority value must be a non-negative integer. For example, a deployment could use a header such as
x-message-priority: 10or3gpp-Sbi-Message-Priority: 10, then configure integer ranges that classify priorities into different shedding policies.The parsed priority is mapped into configured priority buckets. Each bucket defines a half-open integer range, [start, end), and references an overload manager load shed point. If the parsed priority value falls within one of the configured bucket ranges and that bucket’s load shed point is currently active, the filter rejects the request locally using Envoy’s existing overload response behavior:
503 Service Unavailablewith the envoyoverloaded body.Requests are allowed to continue when:
missing-headerrejection is enabledinvalid-headerrejection is enabledThe filter also supports an optional default load shed point. When configured, it is used as a fallback for requests with missing, invalid, or unmatched priority values, allowing users to apply a baseline overload policy to otherwise unclassified traffic.
Note that this filter is much more configurable than the original proposal I had in the linked issue (especially when it comes to default bucket and the rejections config) , this was done in order to make it more flexible to accommodate use-cases that are not exactly the one that was described originally.
Risk Level: Low since the feature is implemented by an independent opt-in filter
Testing: Added unit and integration tests
Docs Changes: Added dedicated doc for the filter
Release Notes: Added mention in the release notes
Platform Specific Features: not present
Fixes #Issue: Close #43552