Hi, Bill.
The final destination doesn't look bad, really. The intermediate hops show some latency that doesn't show up at the final destination, which basically means they don't prioritize creating an ICMP reply as high as passing data through (not entirely unusual).
Because the final destination doesn't show much of an issue, it's hard to speculate on what's going on. Without a problem to troubleshoot, we're not going to have much luck finding a problem in the earlier hops either.
We discuss this concept a bit here:
http://www.nessoft.com/kb/24and
http://www.nessoft.com/kb/2It looks like you're using 1 minute trace intervals here. That's pretty long. With the bandwidth you appear have (based on your latency), I'd suggest using something a lot more often. For initial troubleshooting, I'd suggest using 15 seconds as a maximum (that means an outage of 10 seconds could be missed), but even better something like 1 second or 2.5 seconds. The bandwidth implications are minimal (56 byte packets X 13 hops = 728 bytes. Returning packets are similarly sized), and you'll be able to catch patterns and outage lengths a lot better.
- Pete