Handling state (data) in a Cloud Native way - re: Stateless

[taylor]

When stateless is seen, that is a goal, that is part of the thinking about handling state/data in a cloud native way.

The K8s native best practices for handling state would be what we are looking for along with when they are not appropriate.

What are use cases and or networking applications that need access to and/or handle state for themselves or applications?

[ErvinsK]

IMO, in a telco way all connection- or session-oriented applications are state-full. Cloud native way to handle states are by using an external key-value data store instead of storing states internally. All non-5G mobile packet core (EPC) functions are state-full - SGW/PGW/PCRF...and even 5G Core is state-full as long as legacy GTP protocol is still used.

[fkautz]

Is there state that exists beyond the connection that the system cannot store in a database? If not, how is this different from an ephemeral TLS session to a stateless micro service?

The idea behind "stateless" is no persistent state exists in the service. Ephemeral state which doesn't cause significant downtime (aka breaking your SLAs) if lost is ok.

[ErvinsK]

As far as my knowledge and experience in particular with GTP protocol go, there are no such states that cannot be stored in external database. Usually, it is a question of additional overhead and latency that add up when stateless microservice should store and query states to/from external KVS. As of now, our team has achieved a complete separation and stateless-ness for GTP-C but handling GTP-U states are bound to the packet processing performance...but as you mentioned we have achieved the state when even losing ephemeral states of GTP-U tunnels we can restore overall state of connection quite promptly (some packets are lost). GTP-U in the essence is quite a stateless protocol except mandatory mapping of tunnel endpoints, i.e. TEIDs, but PCEF (e.g. traffic shaping/rating/QoS) is messy!

[rmerz]

@ErvinsK Isn't there logic on the UE that needs to be carefully taken care of?
But beyond that, I agree. To me, the important factor is the SLO

[ErvinsK]

For UE (if end user device is meant) GTP tunnel is completely transparent - UE is not even aware of tunneling :) IMO, the next best thing what should come next is the new method to substitute GTP protocol - e.g. as one of the candidates = SRv6 that adds additional flexibility and program-ability.