envoyproxy / envoyproxy/envoy

Connection pool parameters at Endpoint level

Open
#42,251 8 comments 0 reactions 1 assignee Claimed by @grnmeira View on GitHub
area/connection enhancement no stalebot
Dominant language
C++
Stars
28.9k
Forks
5.6k
Avg merge
1d 20h
Merged PRs (30d)
437

Description

### Problem/Solution

Connection pooling options like the ones present in HttpProtocolOptions or Http2ProtocolOptions would be enforced at global or cluster level only. Being able to set some of those options only in a particular endpoint is desirable when tunnelling is involved in multi-cluster scenarios.

In Istio we have a use case for having Envoy cluster with endpoints that might benefit from different connection pooling properties for some endpoints. The reason for wanting different pooling properties is because some endpoints represent gateways and there might be multiple different endpoints behind the gateway, so ultimately, such endpoints represent multiple servers. Gateways in this case can't demultiplex the requests in the same HTTP2 connection and load-balance on the request level. Because of that we want to be able to control how many requests get multiplexed together, but, on the other hand, we'd like to avoid creating a separate endpoint for each server behind the gateway as it's wasteful compared to just giving the gateway an appropriate weight.

### Proposal

Add an additional API to **config.endpoint.v3.LbEndpoint**, let's call it "**connectionPoolingOptions**" for now. That would allow us to set the following Http(2)ProtocolOptions at an endpoint level: **max_concurrent_streams**, **max_requests_per_connection** and **idle_timeout**. They would preserve the same current syntax and semantics, but they'd be enforced only at the endpoint where they were set. If these options are not present, we assume the current behaviour. Note that **max_concurrent_streams** would still effectively have the minimum value between what's set for the endpoint and what's taken from the negotiation with the server (through SETTINGS frame).

Also, we can add a boolean option **propagate_negotiated_stream_limits**. This option, with the default set to "true", when set to "false" would prevent stream limits negotiated through SETTING frames in HTTP/2 to be applied to the whole cluster, scoping the limits only to the respective endpoint.

Example:

```
...
- lb_endpoints:
- endpoint:
address:
socket_address:
address: 192.168.0.1
port_value: 9084
- endpoint:
address:
socket_address:
address: 192.168.0.2
port_value: 9084
connection_pooling_options:
max_conccurent_streams: ...
max_requests_per_connection: ...
idle_timeout: ...
propagate_negotiated_stream_limits: ...
```

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.