session affinity: source ip

[snqk]

Please describe the problem you have

Contour supports sticky sessions through session affinity, and more specifically through loadBalancerPolicy strategy: Cookie.

When implementing workloads where you'd need tls passthrough, it'd be useful to have the source (/ client) ip and route requests to the same upstream.

I am not sure if that is possible today in envoy though.

[sunjayBhatia]

Envoy supports load balancing on source IP: https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/route/v3/route_components.proto#envoy-v3-api-msg-config-route-v3-routeaction-hashpolicy-connectionproperties

We support request header hashing as a load balancing policy and could extend it to support connection propertly/source IP load balancing: https://projectcontour.io/docs/v1.15.1/config/request-routing/

[snqk]

@sunjayBhatia thanks for your response!

I'm afraid headers won't be readable through a tcp_proxy in the case of a TLS passthrough right?

[sunjayBhatia]

Correct but the connection property hashing feature isn’t related to the http headers, to clarify they are separate hash policies we can make configurable

[youngnick]

Thanks for raising this issue @sarthak40!

This is probably linked to similar issues:
#3099
#3044
#3142
that are also about new hash policy options. I'll make sure it's put in the "to be investigated" bucket there as well.

[xaleeks]

Source IP seems highly useful for session affinity. And we should consider allow specifying the source IP in combination with headers for generating the hash value, leveraging the terminal:true to advance through the set of conditionals. All on a per route basis. Can we investigate this design for v1.17? I'm going to tag it for visibility. cc @skriss

Looking at the issue Nick linked here #3044, it seems we can leverage the parameters afforded by Envoy? ie. the TTL can be useful as well.

Do you have a preference for what the stanza should look like within httpproxy? @sarthak40

[xaleeks]

@youngnick do we have bandwidth to tackle this in 1.18?

[youngnick]

So, we don't have bandwidth to work on this for a little while, moved to the Prioritized Backlog.

[xaleeks]

Can we land this in v1.20?

[youngnick]

It seems likely, given that we have a while before we will (most likely) release 1.20. @sunjayBhatia, any thoughts on how much effort this would be, since you've touched this code most recently?

[sunjayBhatia]

should be much to do here, mainly just adding a new optional field to RequestHashPolicy and wiring that through, writing unit/feature tests since e2e tests are a little tricky here