Please explain me the use of "Reselect on Service Down" and "Least Connection" and also which is better? Consider me new to this

When a pool member fails to respond to a health monitor, the system marks that pool member down and removes any persistence entries associated with the pool member. The BIG-IP system continues to monitor the pool member to determine when the member becomes available again. While a pool member is marked down, the system does not send any new connections to that pool member.

The Action On Service Down feature specifies how the system should respond to already-established connections when the target pool member becomes unavailable.

The BIG-IP system takes no action on existing connections, and removes the connection table entry based on the associated profile's idle timeout value. The BIG-IP system sends a TCP Reset (RST) or ICMP Unreachable once idle timeout is reached. This is the default setting. This is the best option for most common scenarios, as this allows for endpoints to resume gracefully on their own. This may be a good choice for clients that transfer large amounts of data, as the pool member may recover itself before the connection is reset, allowing the large transfer to continue.

The BIG-IP system sends RST or ICMP messages to reset active connections and removes them from the BIG-IP connection table.This may be a good choice for clients that need to be notified of pool member state changes sooner than the configured idle timeout period for that virtual server. Once the target pool member is deemed unavailable, the BIG-IP system immediately alerts the client by resetting the connection, causing the client to attempt a new connection.

The BIG-IP system silently removes the connection table entry. You should carefully consider this option, as the client receives no feedback from the BIG-IP system regarding the connection state. However, this option works well for short-lived, connectionless protocols, such as UDP. For example, DNS queries.

The BIG-IP system manages established client connections by moving them to an alternate pool member without a connection teardown or setup.

Least connection is all together a different thing. Its a pure load balancing algorithm. It measure the current connection on every pool member based on the number on entries in its connection table. The lower is always treated best. If in case any pool member goes down, it will simply tear its existing connections and use remaining pool members (starting from the one with least number of connections).

Just including the following ref https://support.f5.com/kb/en-us/solutions/public/15000/000/sol15095.html, to warn on the Reslecet option - it is NOT what the documentation has traditionally said - only works in very specific cases

This option is only appropriate for:

* Virtual servers with address and port translation disabled
  *Note*: This is default for FastL4 type virtual servers, such as network or wildcard forwarding.
* Transparent pool members, such as firewalls, routers, proxy servers, and cache servers
  *Note:* Transparent devices can forward packets to destinations without regard for the state of the connection.
UDP virtual servers

"None" is the default for good reason.

Thanks a lot Amanpreet & IheartF5...So do you have any idea which is better a algorithm to use - Least Connection or Round Robin or any other ?

Which is better? It depends.

Which one is better for you? Without understanding your environment and knowing the reason for your current load imbalance I couldn't say, however if you currently have an imbalance with RR, it can't hurt to try Least Connections to see if evens out the load. But there may be something else at play here....

When you talk about publishers....you aren't running Adobe CQ/AEM are you?

Hi IheartF5,

Yes, I am running Adobe CQ 5.6 and currently using Round Robin algorithm. I am also not sure why this imbalance in request traversal is happening and I just saw the logs and was baffled to see that monitor status of one of the publisher kept on oscillating up & down every few seconds.

Well that would explain why you have load imbalance - it's not the metric you are using, it's the instability of the publish server. Resolve that and you should resolve the imbalance.