Hi Ben,
please find my inline comments preceded by [ML].
Il 05/02/2026 16:35, Ben Schwartz ha scritto:
------------------------------------------------------------------------
*From:* Mario Loffredo <[email protected]>
> We opted for EoH to take advantage from being independent on TCP.
I don't understand. Could you clarify?
[ML] EPP over TCP, i.e. RFC 5734, maps an EPP session to a TCP
connection. Therefore, TCP connections should persist as logn as EPP
sessions are alive. However, more importantly, when a TCP connection is
lost, the related EPP session ends and no further EPP commands can be
issued over that session. In L4 load balancing, TCP connections are kept
alive by backend servers. When a backend server crashes or needs to be
shut down for maintenance, all ongoing connections are dropped.
L7 load balancing is more suitable when maintaing user sessions is
essential.
Furthemore, L4 load balancing is not always supported on cloud platforms
or is complex to implement. Many RSPs that operate multiple domain name
registries are planning to migrate their services to a cloud envionment,
and EPP over HTTPS supported by a L7 load balancing would be the most
suitable solution.
> 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.)
[ML] Yes, exactly. An EPP session is mapped to an HTTP session.
Therefore, the EPP session is not tied to a physical connection, but to
a logical one.
In particular, when the EPP session information is stored outside the
pool of backend servers, an EPP command can be processed by any backend
server, not necessarily by the one that initiated the HTTP session.
As a consequence, no EPP session is lost when a backend server goes down.
> 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?
[ML] The duration of sessions various, where a best practice is for the
client to maintain a pool of established stateful sessions that are kept
alive in the background via the EPP Hello Command. Some registrars will
establish a session per command, but that introduces undue overhead
(e.g., TLS handshake and authentication via the EPP Login Command) in
supporting a large set to provisioning commands. Some registries
include connection policies for registrars (e.g., bandwidth limit,
connection limit) to meet non-discriminatory access that encourages the
registrars to maintain a pre-defined set of EPP connections to process
provisioning requests from their website.
> 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.
[ML] Aside from the benefits of deploying an L7 load balancer on a cloud
environment which is one of the reason supporting the implementation of
EoH, EPP was designed to be stateful, so any solution that enforces
session stability is required.
Best,
Mario
--Ben
_______________________________________________
regext mailing list [email protected]
To unsubscribe send an email [email protected]
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
