EP-specific connection pool configuration

[grnmeira]

** Waiting for review to make sure this is the right path for this feature **

Commit Message: Adds a typed protocol configuration that allows setting some connection pool parameters specifically for certain endpoints with a metadata match criteria. Additional Description: Risk Level: Testing: Docs Changes: Release Notes: Platform Specific Features: [Optional Runtime guard:] [Optional Fixes #Issue] [Optional Fixes commit #PR or SHA] [Optional Deprecated:] [Optional API Considerations:]

[repokitteh-read-only[bot]]

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/). envoyproxy/api-shepherds assignee is @wbpcode CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).

:cat:

Caused by: https://github.com/envoyproxy/envoy/pull/42565 was opened by grnmeira.

see: more, trace.

[krinkinmu]

I think creating a new API is going to be a tougher sell than reusing an existing proto. If some bits aren't used by the pooling logic, we should check if we can wire them to the places that use them.

On Tue 16 Dec 2025, 11:39 Gustavo Meira, @.***> wrote:

@.**** commented on this pull request.

In api/envoy/extensions/upstreams/http/v3/http_protocol_options.proto https://github.com/envoyproxy/envoy/pull/42565#discussion_r2622923322:

@@ -221,3 +223,36 @@ message HttpProtocolOptions { // not merged. config.route.v3.RetryPolicy retry_policy = 11; }

+// [#next-free-field: 2] +// Aggregates endpoint-specific protocol options. Each item has +// a "metadata match" field that allows for specific endpoints to +// pick up a particular configuration. +message EpSpecificHttpProtocolOptions {

• // Defines endpoint-specific HTTP protocol options. These options
• // are only applied to endpoints for each their metadata match the
• // ep_metadata_match string field. Otherwise the endpoint will
• // pick the cluster's protocol options.
• message EpSpecificOptions {

I'm hesitant to use such an extensive API for such a small implementation. If I remember correctly Http2ProtocolOptions even exposes things that are not (currently) handled by the connection pooling classes.

— Reply to this email directly, view it on GitHub https://github.com/envoyproxy/envoy/pull/42565#discussion_r2622923322, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAI7Q4775NN3IPBCXFD5VED4B7VNVAVCNFSM6AAAAACOXEISLKVHI2DSMVQWIX3LMV43YUDVNRWFEZLROVSXG5CSMV3GSZLXHMZTKOBSGY2TIOJQGE . You are receiving this because you were mentioned.Message ID: @.***>

[grnmeira]

I think creating a new API is going to be a tougher sell than reusing an existing proto. If some bits aren't used by the pooling logic, we should check if we can wire them to the places that use them.

@krinkinmu Had a look at this and it seems reasonably straightforward. The testing will be more complicated than the implementation. I'll add that to this PR.

[wbpcode]

Although I agree this may make sense in some specific scenarios, but it also may never be necessary for most users in most of cases. So, all my requirements are to reduce the effect to our core code base and keep the API simple.

That's say, without any changes to its interface] needn't to be our target. Our target should be keep it simple, and if possible, make it a independent extension. And if changing the ClusterInfo interface or change HttpProtocolOptionsConfig could help could help, it is fine to change.

And TBH, I didn't get a clear graph about what API is the appropriate API looks like. (A very coarse idea in my mind is may be we can attach some additional metadata in the host and we can use it if necessary (and the feature is enabled).

Maybe @markdroth could give some better suggestions. cc @envoyproxy/api-shepherds

[grnmeira]

Thanks for the review @wbpcode

And TBH, I didn't get a clear graph about what API is the appropriate API looks like. (A very coarse idea in my mind is may be we can attach some additional metadata in the host and we can use it if necessary (and the feature is enabled).

Do you mean like using metadata in the endpoint to set those options? Do we do that with any other type configuration at the moment?

[wbpcode]

Do you mean like using metadata in the endpoint to set those options? Do we do that with any other type configuration at the moment?

Nope. we have no much per-host things except the lb metadata. So, I also didn't figure out a good solution now. Still need to involve others' mind in.

[wbpcode]

By the way, couldn't make it the hosts (with special protocol setting) as independent cluster? Then we can use other ways to composite these clusters works like single one?