Re: [radext] Server identity and RFC7585bis

[Alexander Clouter <[e-mail]>]

Hello,

On Fri, 12 Apr 2024, at 09:35, Jan-Frederik Rieckers wrote:
> The purpose of defining a way to check if it is the same server is to 
> make sure that we mark broken servers as down and don't use them in our 
> load-balancing any more.

No load balancer should do this.

There can be many reasons why one of N connections to the same application process could stall.

An implementation may wish to service an entire stream socket serially in a single thread. If that thread blocks, other threads servicing other stream sockets will be fine.

Another is you may have multi-path (inc dual-stack) between the target backend server and only one of those paths is broken.

Really, you do not want to be doing this.

This is why load balancers use an out-of-bound health checks. Only the server knows if it is DOWN and is the only system that authoritatively can state this.

Everything else is only able to infer "route is bust".

> 2. Prevent opening unnecessarily many open connections to a server with 
> dynamic discovery, just because the client is not sure if it's the same, 
> while keeping deployment options open (i.e. different policies hidden 
> behind different Server Names, but with the same certificate)

This is a bad reason. TCP connections are cheap.

An idle TCP socket creates no load on the remote system. It actually probably improves performance as routers in between and the OS running the server can all use this for horizontal scaling.

TCP connection pooling is wildly used to lower latency.

Also...consider the compute/resources of maintaining a TCP connection proportional to the cost of servicing a request sent over it; especially as the 'cost' is immortalised over time. I would be surprised if it even rendered as an anti-aliasing artefact on a pie chart :)

Connection cycling ('reload') is a different problem.

Regards