The hop count question is interesting. Is the consensus that it's mostly a customer service issue, where latency isnt affected but customer perception is? Or is it a real latency issue as more routers take a few CPU cycles to make a routing decision.
To some extent, that's an "apples or oranges" statement of the problem. Longer paths present more opportunities for latency to be caused by queueing delays on potentially congested interfaces and such. Customer service is always going to be an issue because the details that lead to a path with more segments providing better service are hard to explain, and real side-by-side comparison is often difficult. Regarding CPU cycles for route lookups: Back in the mid-1990s, route lookups were expensive. There was a lot of hand-wringing, in fact, about how doing route lookups at every hop in larger and larger FIBs had a negative impact on end-to-end performance. One of the first reasons for the existence of MPLS was to solve this problem. In the late-1990s, though, ASIC-based route lookup made the problem go away - route lookups could be done in just a couple memory cycles, with retrieval times comparable to looking up MPLS labels. Problem solved (and the MPLS people moved on to try the TE problem space to justify their existence). In the case of modern hardware, forwarding delay due to route lookup times is probably not a contributing factor to latency. "More hops" can mean many other things in terms of delay, though - in both the "more delay" and "less delay" directions, and countering the "more hops means more delay" perception will (I think) always be a challenge. Stephen