QOS or more bandwidth

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.

	Sean. 