While the IP SLA functionality of the ASA is, in general , quite useful, it still lacks an essential bit of flexibility.
The ASA's SLA feature set is a tiny subset of that available on IOS routers. While IOS routers allow for SLAs to be based on such criteria as jitter and exact packet loss levels (and many non-ICMP based factors), the ASA is limited to a basic ping test (ipIcmpEcho reachability) which can be directed via a specific interface. For example:
sla monitor 1
type echo protocol ipIcmpEcho 188.8.131.52 interface outside
This is reasonably good for detecting basic link availability under most circumstances. However there is one significant shortcoming. While there is a way of specifying an interval between SLA iterations (in the above example 100 pings are performed every 42 seconds), there is no way to specify the interpacket interval (i.e. between pings). Traffic analysis reveals that the fixed interval is approximately 20ms, meaning that all 100 pings (the maximum allowed) are sent within about 2 seconds. While the address is considered reachable for SLA purposes so long a one ping per iteration is successful, this means that the maximum outage that can be specified as tolerable is effectively 2 seconds. Let's say, for example, that I wish to have an ASA drop its primary default gateway entry and fail over (in our case backhauling via the WAN) only if an Internet address becomes unreachable for 10 seconds. There doesn't seem to be any way to do this on the ASA. (Frankly, I don't really need 100 pings. I'd be happy with 20 pings spaced 500ms apart.)
I've actually bumped into this problem in production. We have one site (of many) where we're pretty much stuck with an ISP who thinks that a 2-4 second outage a few times a day is acceptable. For the foreseeable future, it looks as though we'll have to deal with it, and I really don't want my SLA triggering and failing over unless the outage is prolonged. (Note that increasing the timeout will have no effect on this, for when the link is down when all the packets are sent, it makes no difference how long you wait; there will be no reply even if the link came back up a couple of seconds later.)
I do realize that I could, instead, set up a more complicated SLA on the IOS-based core router at that location, but I want to keep this as elegant as possible.