Cogent service

Fri Sep 20 21:56:00 UTC 2002

> 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