Merit Network
Can't find what you're looking for? Search the Mail Archives.
  About Merit   Services   Network   Resources & Support   Network Research   News   Events   Home

Discussion Communities: Merit Network Email List Archives

North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Re: The Qos PipeDream [Was: RE: Two Tiered Internet]

  • From: Stephen Sprunk
  • Date: Fri Dec 16 15:14:16 2005

Thus spake "Christopher L. Morrow" <christopher.morrow@mci.com>
On Fri, 16 Dec 2005, Min Qiu wrote:
Not 100% true.  Through I agree QoS has little impact in the core
that has OCxx non-congested backbone (more comments below).  In the
edge, it does has its place, as Stephen Sprunk and Mikael Abrahamsson
explained/described.  I recalled we were busy at one time to find out
why one of our _most_ important T1 customer's poor VoIP performance.
It turned out his T1 was peaked in those peroid.
yup, for t1 customers (or dsl or dial) qos matters only if your like is
full when you want to do something with stringent delay/jitter/loss
requirements (voip).  Possibly a better solution for both parties in the
above case would have been MLFR ... possibly. (someone would have
to run the numbers, I'm not sure how much the 'qos' service costs in
real $$ not sales marked-down-for-fire-sale $$)
MLFR (you mean FRF.8?) works, but you first need to learn how to do FRTS, which is a nightmare in itself. MLPPP LFI is trivial to set up.

However, MLFR/MLPPP only help when paired with an intelligent queueing algorithm; with FIFO and even WFQ they're useless. You've gotta go to CBWFQ/LLQ to get the benefits.

it only move the threahold in the core from DC3 to OC12 or OC48 (see
Ferit and Erik's paper "Network Characterization Using Constraint-
Based Definitions of Capacity, Utilization, and Efficiency"
 (http://www.comsoc.org/ci1/Public/2005/sep/current.html I don't have
the access).  I'm not sure the study can applied to customer access
edge where traffic tend to be burst and the link capacity is smaller in
general.
Maybe part of the discussion problem here is the overbroad use of 'QOS in
the network!' ? Perhaps saying, which I think people have, that QOS
applied to select speed edge interfaces is perhaps reasonable, I'd bet it
still depends on the cost to the operator and increased cost to the
end-user. it may be cheaper to get a second T1 than it is to do QOS, and
more effective.
For some scenarios, yes, but in most environments the peaks would still fill the pipes, just for half the time. And, as we all know, the faster the network gets, the more creative ways people find to fill those pipes. It's a rat race, but your telco salescritter will love you for it.

Overprovisioning the last mile is, at least for now, far more expensive than training a monkey to apply a cookie-cutter MLPPP/LLQ config; from the comments here, consensus is the opposite is true in the core. My experience is with large-but-slow networks (thousands of sub-T1 sites) so I can't say how true that is, but it sounds right.

Alternately, customers could use other methods aside from QOS to do the
shaping, assuming 'QOS' is defined as tos bit setting and DSCP-like
functions, not rate-shaping on protocol or port or source/dest pairs.
QoS has lots of different meanings, thanks to the marketeers. The one most customers think of, and the only one that's provably wrong, is "QoS is a magic wand that gives you free bandwidth."

S

Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking




Discussion Communities


About Merit | Services | Network | Resources & Support | Network Research
News | Events | Contact | Site Map | Merit Network Home


Merit Network, Inc.