You are asking for projections in a scenerio where bandwidth
demand drops, and bandwidth supply remains constant or grows.
Projection: Bandwidth prices are dropping. QOS still sucks.
regards,
fletcher
Altho you need to have different policies for your core and for your
customers.. it may be practical to increase bandwidth on the core and
avoid QoS (which imho should never be employed on the core).. but its not
always within a customers budget to upgrade from low speed circuits.
I think as the prices drop, smaller businesses are coming online but still
trying to use high bandwidth applications. As they are unable to pay for
the extra bandwidth (no matter how cheap it might seem) there would appear
to be a good case for using QoS on your PE/CPE links.
Steve
Date: Tue, 29 May 2001 14:13:50 +0100 (BST)
From: Stephen J. Wilcox <steve@opaltelecom.co.uk>Altho you need to have different policies for your core and for your
customers.. it may be practical to increase bandwidth on the core and
avoid QoS (which imho should never be employed on the core).. but its
not always within a customers budget to upgrade from low speed circuits.
Although I generally agree, how does one keep QoS out of the core for CBR
and jitter-sensitive applications?
I think as the prices drop, smaller businesses are coming online but
still trying to use high bandwidth applications. As they are unable to
Many here must continually explain on other lists that speed and volume
are totally different games. "High-speed" access != "high volume for
below cost". Ughh. (If I wire my house with a 400A main, and insist
on running 30kW all the time, I'm going to get a biiig electric bill...)
Eddy
> Altho you need to have different policies for your core and for your
> customers.. it may be practical to increase bandwidth on the core and
> avoid QoS (which imho should never be employed on the core).. but its
> not always within a customers budget to upgrade from low speed circuits.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).
> I think as the prices drop, smaller businesses are coming online but
> still trying to use high bandwidth applications. As they are unable toMany here must continually explain on other lists that speed and volume
are totally different games. "High-speed" access != "high volume for
below cost". Ughh. (If I wire my house with a 400A main, and insist
on running 30kW all the time, I'm going to get a biiig electric bill...)
Exactly! If you continue to increase the requirements with growing
bandwidths you have no net gain. (A lot like each new release of Windows
has more features to take advantage of faster CPUs that means they always
remain slow!)
Steve
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.