Hey guys, one thing that would save us (me) a lot of time and hassle would be some sort of packet loss threshold, above which, a speed fusion connection would fail over to a secondary link. (or, if the connection is running on both links at once, it would drop that link from the bonded tunnel)
Here in NYC we often run into degraded circuit/packet loss issues due to the age of the infrastructure.
Is this something you could consider?
Thanks!
-Ryan
For a little additional info:
We’ve even had routing issues between different ISPs at different sites. This is the sort of thing that just testing the circuit via DNS isn’t going to resolve but tests between the different interfaces at the different sites should.
Yes this actually makes a lot sense. I am sure this is not the first time I come across this and definitely this is something we will look into.
Based on your experience, how much of a packet loss would hurt your bonded throughput noticeably? And does the difference in latency between your WAN links have any impact?
I think it all depends on whether or not I have VOIP traffic running over the tunnel. If I do, I’m very concerned with packet-loss, even just a little. If I don’t, I’m much less concerned and would probably prefer to have the additional bandwidth with a little packet loss instead of dropping that circuit from the bonded tunnel.
Sounds like it should be a configurable setting?
If I don’t have VOIP traffic and the circuit is dropped from the tunnel (mostly used for, say, DFS replication) at 0.5% packet loss I won’t be happy but if I DO have VOIP or other real-time interactive applications which don’t handle packet loss well and it waits until 5% loss to drop the circuit I’m also not going to be happy.
Most of our circuits are within 30ms of each other which isn’t enough to prefer a lossy 10ms of response time over a stable 40ms, for example.
It does sounds like we want a configurable setting. It would be awesome, I am sure, if SpeedFusion could learn when to tolerate a relatively high packet loss link and when not to (and also how high is high). But all of this requires SpeedFusion be to determine the user experience which is pretty difficult to quantify ummm…
It would be awesome, but there’s always the outside case: People using ports you don’t expect, new applications, etc etc, unless you’re willing to treat all UDP traffic as real time traffic when justifying low % packet loss failover. So even if you DO spend the time to create an analysis engine or something to determine the appropriate failover level you’d still have to allow manual configuration as well. I’d spend that time on other priorities and leave it manual.
That’s actually what I am thinking too. A quick configurable setting could be a good start. Even when we have different types of traffic, traffics that have different levels of tolerance for packet loss, going across at the same time, we could still stick with the setting that works best for the most packet loss sensitive traffic.
That seems reasonable, and in this case, the guy running only DFS traffic or something can easily increase the threshold.
How about packet loss notification (alerting) first? Might be a nice stepping stone into failover.