Re: [regext] Re: draft-ietf-regext-epp-https-02 early Httpdir review

________________________________
From: Mario Loffredo <mario.loffredo@iit.cnr.it>


> We opted for EoH to take advantage from being independent on TCP.


I don't understand.  Could you clarify?


> We've explored every solution for managing HTTP sessions on a load-balancing architecture, from sticky sessions to outsourcing session management to a Redis cluster. The latter solution offers us maximum flexibility, scalability, and fault tolerance and implement load balancing very efficiently.


Thanks for sharing.  Are you relying on the "Cookie" request header to link HTTP requests with their EPP session?  (This seems to be the suggestion in draft-ietf-regext-epp-https-02.)


> My opinion is that WebSocket would not be the right solution, at least not as efficient as traditional HTTP connections, since WebSocket connections between client and server are stateful and long-lived via the load balancer.

Could you give us some sense of the typical session duration and number of commands per session?


> In this scenario, sticky sessions would be the only option to implement load balancing for WebSocket, but based on our nearly twenty years of experience and also widely described in literature, this wouldn't balance the load efficiently and would require addressing some additional issues, such as maintaining connection limits, keeping the service up during maintenance operations, and handling a huge volume of requests.


It seems like maintaining session limits is required in either design, and the number of requests is the same either way.  However, I appreciate that if each session is bound to a connection, then a session cannot easily outlive its server instance.  To determine whether this is acceptable, it would help to understand how long sessions normally last, and how much of a problem it is when a session is closed by the server.


--Ben