Upstream PROXY protocol results in unbound number of connection pools

[ggreenway]

When using upstream PROXY protocol with tcp_proxy, a new connection pool is created in the cluster for each unique combination of downstream IP:port and upstream host.

For many typical use cases, where the downstream clients are not from a tightly constrained set of IP addresses, this results in a nearly-infinite number of connection pools, which wastes memory. Even if the clients are from a very small set of IPs, each could typically use 30,000 ephemeral ports, which could still result in a very large number of connection pools. The connection pools are never removed until the cluster is removed (via CDS, or process shutdown).

#13061 would have fixed this, but it was never completed/merged.

[klarose]

I wonder if the original_src filter work I did a while back is susceptible to this as well. I thought that I had implemented some cleanup and reuse logic here (https://github.com/envoyproxy/envoy/blob/57976d142005cda6ce54ec215cafceebe4fc1aef/source/common/upstream/conn_pool_map_impl.h), but it's possible I missed it.

I bring this up, because it has similar constraints to the proxy protocol: a given upstream connection can only really carry requests from a given downstream, so we essentially need a connection pool per downstream connection.

[ggreenway]

If the circuit breaker for number of pools is set, that will set a bound on the number of http pools. However:

• If the number of pools is large, performance won't be very good because we have to do a linear search everytime we want to free a pool to add another
• tcp conn pools don't honor that setting at all, so tcp_proxy configurations don't have any way to limit the number of pools

[github-actions]

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.

[ggreenway]

Not stale; PR in progress.