
While its generally more effective to add more bandwidth than rationing it with QOS, with the recent downturn in capital markets will QOS become more popular? If your budget for bandwidth has been cut, I'm not sure people will have any budget for QOS either. But what QOS features are included in the standard product offerings?

On 28 May 2001 23:17:46 -0700 Sean Donelan wrote:
While its generally more effective to add more bandwidth than rationing it with QOS, with the recent downturn in capital markets will QOS become more popular?
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 On Tue, 29 May 2001, Fletcher E Kittredge wrote:
On 28 May 2001 23:17:46 -0700 Sean Donelan wrote:
While its generally more effective to add more bandwidth than rationing it with QOS, with the recent downturn in capital markets will QOS become more popular?
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

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 --------------------------------------------------------------------------- Brotsman & Dreger, Inc. EverQuick Internet Division Phone: (316) 794-8922 --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.

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 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...)
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
Eddy
---------------------------------------------------------------------------
Brotsman & Dreger, Inc. EverQuick Internet Division
Phone: (316) 794-8922
---------------------------------------------------------------------------
Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature.
These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.

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.
participants (5)
-
E.B. Dreger
-
Fletcher E Kittredge
-
Pete Kruckenberg
-
Sean Donelan
-
Stephen J. Wilcox