It's attempting to round-robin TCP connections to different VIPs on different ports.
Assume the VIPs are (VS_one/VS_two/VS_three could in fact be direct servers instead of VIPs)
VS_front:80 -> this_irule
VS_one:88 -> pool_for_server_1
VS_two:87 -> pool_for_server_2
VS_three:86 -> pool_for_server_3
likely intention:
user_A hits VS_front and gets redirected to VS_one. counter "::c" gets incremented
user_B hits VS_front and gets redirected to VS_two. counter "::c" gets incremented
user_C hits VS_front and gets redirected to VS_three. counter "::c" set to 0
user_D hits VS_front and gets redirected to VS_one. counter "::c" gets incremented
You're best off moving to a single VS loadbalancing the backend of three servers in a single pool with persistence on (probably cookie), and least connections load balancing method.
In modern BIG-IP v11.4 you can set a connection limit and queueing on the VS, connection limits on the pool members, and all sorts of other sugar to manage this cleanly. AVR would give you visibility into how well things are getting balanced.