Naming: session persistence

[stephanwesten]

Hi,

During a kubecon eu presentation the term ‘session persistence’ was mentioned. For a (java) developer this means persisting the http session state to storage.

Imo ‘sticky sessions’ is a better term. This is commonly used terminology and avoids above confusion.
Also still gives room to differentiate between affinity and ‘stickyness’

[shaneutt]

Thank you for attending, and thank you for bringing this up.

/cc @gcs278

Grant I'm curious to your thoughts on this one, and for us to come up with some kind of explicit criteria for the naming (which we should document in the GEP). E.g. if we find that Java's nomenclature is also reflected in several other places, maybe we consider a name change? Or if we think it's pretty isolated or we find some very good references we at least document why we chose what we chose, and make sure we add notes to our documents to point out "hey, you might think of this as sticky sessions" and leave some clear breadcrumbs behind for future readers to follow? In any case, naming is the hardest part of any project 😉

[gcs278]

Yea I agree it's worth documenting the evidence of our naming decision here & in the GEP. For context, when I started this GEP, I read a HaProxy Blog early on, and they distinguished "Session Persistence" and "Session Affinity". I took that and ran with it. I brought it up at the community meeting and folks seemed to like it, so it has stuck so far. But let's get it right, if we need to change for clarity, I'm open to that.

I think there are two major questions for me:

1. Is the distinction between Session Persistence and Session Affinity (hard & soft persistence/affinity), as we define it now, worth it?
2. Is Session Persistence (& Session Affinity) the right name?

For # 1, I wonder if the constructed distinction is confusing folks for the reasons:

1. Not because it isn't logical, but because Session Persistence and Session Affinity are already prescribed names that mean various things among implementations.
2. Most, if not all implementations don't distinguish between the two. Istio doesn't distinguish.

I could be placing too much value on Istio APIs, but also it's worth asking folks if this concept of hard & soft persistence makes sense or is more confusing than it's worth.

For # 2, regarding the literal naming, personally I liked the symmetry between the two (Session Persistence & Session Affinity). However, I do agree with @stephanwesten that there is a connotation of persisting to storage, it's right in the Java docs. But would persisting to storage ever be an API in a Gateway API implementation? Maybe it's not worth the risk keeping "Session Persistence" if "Sticky Sessions" an equivalent name that avoids this possibility. I'm open to that.

So, to your point if "Session Persistence" is reflected in other places, I threw together this table:

Implementation	Name for Session Persistence (Strong)	Name for Session Affinity (Weak)	Distinguishes Between Persistence & Affinity?
Acnodal EPIC	N/A	N/A	N/A
Amazon Elastic Kubernetes Service (alpha)	N/A	N/A	N/A
Apache APISIX (beta)	Sticky Sessions	N/A	No
Avi Kubernetes Operator (tech preview)	Session Persistence	Session Persistence	No
Azure Application Gateway for Containers (preview)	Session Affinity	N/A	No
BIG-IP Kubernetes Gateway (beta)	N/A	N/A	N/A
Cilium (beta)	N/A	Session Affinity	No
Contour (beta)	Session Affinity / Sticky Sessions	N/A	No
Easegress (GA)	N/A	N/A	N/A
Emissary-Ingress (Ambassador API Gateway) (alpha)	Sticky sessions / session affinity	Sticky sessions / session affinity	No
Envoy Gateway (GA)	N/A	N/A	N/A
Flomesh Service Mesh (beta)	N/A	N/A	N/A
Gloo Gateway 2.0 (beta)	Session Affinity / Sticky Sessions	Session Affinity / Sticky Sessions	No
Google Kubernetes Engine (GA)	Session Affinity	Session Affinity	No
HAProxy Ingress (alpha)	Affinity	N/A	No
HAProxy Kubernetes Ingress Controller (GA)	Session Persistence	N/A	No
HashiCorp Consul	N/A	N/A	N/A
Istio (beta)	Strong Session Affinity	Soft Session Affinity	No
Kong (GA)	Persistent Session	N/A	No
Kuma (beta)	N/A	N/A	N/A
LiteSpeed Ingress Controller	N/A	N/A	N/A
NGINX Gateway Fabric (GA)	N/A	N/A	N/A
Nginx	Session Persistence	Session Persistence	No
STUNner (beta)	N/A	N/A	N/A
Traefik (alpha)	Sticky Sessions	N/A	No
Tyk (work in progress)	N/A	N/A	N/A
WSO2 APK (GA)	N/A	N/A	N/A

And here are the results (this is just an rough estimation):

pie title  What Implementations Call "Session Persistence"?
    "Session Persistence" : 3
    "Persistent Session": 1
    "Session Affinity" : 7
    "Sticky Sessions" : 5

Loading

To me, it's a bit of wash between "Session Persistence" vs. "Sticky Sessions", but "Session Affinity" technically wins...though "Affinity" doesn't conjure up a "strong" connotation for me.

Just enumerating reasonable outcomes, not in a particular order:

1. No change: Strong "Session Persistence" & Weak "Session Affinity"
2. Strong "Sticky Sessions" & Weak "Session Affinity"
3. Merge hard & soft persistence: Only "Sticky Sessions"
4. Merge hard & soft persistence: Only "Session Affinity"

Sorry for the rambling, hope the table & chart provide some context. Sticky sessions seems reasonable for me, I have no strong reason again, but I'd like feedback. I can bring this up in Gateway API community call, but feel free to continue the discussion here.

[shaneutt]

I appreciate how thorough you were.

Personally I think your distinction you've made between persistence (strong) and affinity (weak) makes sense. I also see the difference in naming as possibly a bit of a "wash" given the table and examples. I'm personally OK with us documenting the information you've provided in the GEP for posterity, and then keeping the current naming but from here on out making a point to note this in several places, e.g.:

Note: In other projects this is sometimes called "sticky sessions" or "affinity". We make a distinction and reserve "affinity" for a "best effort" approach, .......... ETC

Something like that. But that's my 2 cents, I'll give it some time of course for others to chime in here and we'll see.

[gcs278]

We spoke about this at the Gateway API meeting on March 25. Though it was a small meeting, we had mixed opinions. One vote for keeping session persistence & session affinity, and one vote for changing to sticky sessions (or something else). Though everyone agreed defining the split between strong & weak session affinity makes sense.

I think doing this democratically might prove to be problematic. As for my vote, I don't have strong opinions either way. It feels like a wash between naming and I don't think "persistence" should only be restricted to the idea of persisting to storage (e.g. connections can persist too). But updating the name is simple, and may avoid confusion. But having sticky sessions & session affinity, feels asymmetrical and isn't clear how they are exactly related. If I had to suggest something else, I think it would go with the painfully verbose "strong session affinity" and "weak session affinity" to avoid all confusion. But that feels pretty awkward as an API structure.

We all agreed that, at a minimum, the GEP should be updated with the information I provided above, and better acknowledging the relationships between the names like you mentioned. I'll take a stab at that. Still open to opinions in the meantime.