QOS or more bandwidth
Sean M. Doran
smd at clock.org
Tue May 29 14:39:07 UTC 2001
| I would disagree and argue that your core needs to be running top of the
| range routers with fat pipes with spare bandwidth, for a large network if
| you run out of CPU or bandwidth your routers will simply fall over.
Which CPU are you worried about? My top-of-the-range routers all
seem to have more than a dozen in them...
The bandwidth I'm worried about right now is on the memory busses;
the optical people who make things that blink lights really quickly
are well ahead of IP's present needs.
| (plus [QoS] will slow down the routing process).
Which routing process?
Assuming you mean packet forwarding will be slowed down, that
really depends on architecture (more modern ones won't show
a measurable slowdown, and even less modern ones don't care
much about work-conserving fancy queueing - consider Villamizar's
projections on SFQ vs CPU/state).
Assuming you mean signalling - well - it depends on how you do it.
Static support for preset "flavours" (DSCP, diff-serv code points
is the jargon - sorry :) ), a small number of priority levels for
WFQ or WRED, and so forth is pretty easy to set up. Reservations-
based signalling (RSVP et al) is a bit harder, and also consumes
more non-human resources.
However, I would worry more about QoS signalling slowing down
human processes, such as debugging problems and handling complexity,
than I would about QoS slowing down high-end packet processing equipment.
That said, since detecting blinking lighs fast enough is not presently
a constraint on growth, a toolset whose principal use is combatting
situations in which there is a bandwidth constraint seems more like
an unnecessary frill than essential equipment.
More information about the NANOG