[38110] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: QOS or more bandwidth

daemon@ATHENA.MIT.EDU (Pete Kruckenberg)
Tue May 29 10:44:49 2001

Date: Tue, 29 May 2001 08:44:19 -0600 (MDT)
From: Pete Kruckenberg <pete@kruckenberg.com>
To: <nanog@merit.edu>
In-Reply-To: <Pine.LNX.4.21.0105291507520.32761-100000@staff.opaltelecom.net>
Message-ID: <Pine.LNX.4.30.0105290836450.14812-100000@localhost.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Errors-To: owner-nanog-outgoing@merit.edu


On Tue, 29 May 2001, Stephen J. Wilcox wrote:

>> Although I generally agree, how does one keep QoS out
>> of the core for CBR and jitter-sensitive applications?
>
> 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.
>
> If you have sufficient bandwidth and your routers are
> running smoothly then there is no use for QoS hence I
> wouldnt use it (plus it will slow down the routing
> process).

QoS isn't just about queueing algorithms and transmit
reordering. QoS-triggered path selection (a la MPLS-TE, PBR)
can be an equally compelling motivation, if the network is
built for differentiated services (which most aren't today,
since a packet is a packet is a packet). This would make
most sense in the core, of course.

Pete.


home help back first fref pref prev next nref lref last post