The approach you are suggesting is completely wrong in my opinion.
Why?
Its a waste of resources, it's like "security through obscurity" patching over a problem rather than fixing it directly, and it's going create complexity that can be avoided through a better designed solution (trouble shoot network issue over three links at once, I don't fancy that!)
So What Then?
As you said yourself, the latency of each link will be fluctuating. I see a few of approaches here, either way, the solution needs to be one that was designed for such a scenario (tackling latency and RTT issues). Look at solutions for this, your actual problem, not the meta problem of "how to use all three links at once?".
Solution One
First, if you have three links, ditch 1 or 2 of them, and re-invest the money on something with a guaranteed latency. ISPs sell point-to-point links (so get one to your destination) with an SLA on delay, and your on for a winner right there. You can keep the third link as a backup if you like.
Solution Two
The second option to use something like Cisco's OER (optimal edge routing). Other vendors have similar technologies, or if you have a *nix firewall/router/gateway for example, you could also script or code a similar solution for yourself. Using Cisco OER as an example, it allows you to set up tests (i.e. ping's) to a destination, it measures the quality of the test, if it degrades to a certain point, traffic is rerouted another way. So you can set up tests for latency and always use the lowest latency route.
Solution Three
MPLS TE - Multi Protocol Label Switching - Traffic Engineering. I know it's a bit of a mouthful, but MPLS-TE allows you to set up tunnels between two end points, and again, route traffic down the lowest latency path. This is a bit more specialised though; you either need a good ISP that can do this for you, or you need to invest in some half decent routers and set it up for your self. You can run MPLS over GRE between to remote routes and set this up.
Solution Four
One possible idea is that you can use multiple VPNs or tunnels between the two ends of your network and introduce per-packet load balancing (round robbin'ing) across all three links. You can do this with Cisco and Juniper routers for example, or again, if you use Linux, you can use a package like teql
, or buy a hardware device like a FireBrick. If all the links have similar latencies (so you aren't mixing ADSL, 3G and fibre) this would work. It generally isn't advised as out of order packets can cause problems in applications, so no mixing of latency style links as I just mentioned. But, I do have it enabled across a couple of links now, and did at my last place, and they are problem free. I'm sure a packet may arrive out of order every now and again, but it must be very rarely, as I don't ever notice any problems.
Solution Five
You mentioned the latency being related to your application. Since I don't know what your application is or how it works, there may always be the outside chance that there is some sanity in me recommending you do something about this at the application layer. I mean, re-code the application to handle higher latency links. Shit happens, even if you implement a magical low latency network solution, shit happens, latency will rise, plan for the worse, code it into your application to handle such undesirable scenarios should the worst happen (faulty planning and all, FMEA etc).