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

On Fri, 16 Dec 2005, Min Qiu wrote:
Hi Chris,
hey :)
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 $$)
i think this is where WRED is used... avoid the sawtooth effect of tcp sessions, random drop some packets and force random flows to backoff and behave. I think I recall WRED allowing (with significant number of flows) usage to reach 95+% or so smoothly on a ds3... though that is from some cisco marketting slides)
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. 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.

Thus spake "Christopher L. Morrow" <christopher.morrow@mci.com>
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.
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.
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

On Fri, 16 Dec 2005, Christopher L. Morrow wrote:
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
Probably. Users, executives and reporters are rarely careful talking about the technical details. They are usually more interested solving a problem. Engineers sometimes get caught up in arguing about the pro's and con's of a particular widget and sometimes miss other ways to solve the real problem. Suppose you wanted your web content to load faster on a user's computer, how would you do it? Could you hire a content distribution network like Akamia to improve the quality of service for your content? Is the Internet a zero-sum game, so if Akamia makes one web site faster does that mean all other web sites must get slower? Instead of paying a CDN, what if an ISP told content providers you could host your content on our server farms close to the end-user connections. If the content provider doesn't pay the ISP to host the content on their network, the content is delivered over the Internet from wherever in the world the content provider data center is located. There are lots of ways to improve the quality of service for some content versus other content. Should ISPs be prohibited from giving a CDN operator space or bandwidth for its servers because they don't have space for every CDN that wants space? Should ISPs be prohibited from operating their own CDN? Doesn't a CDN create an unlevel playing field between content providers that pay to use it over content providers that don't pay for the CDN? If you want to define QoS as a strawman, you can. But it doesn't solve the problem.
participants (3)
-
Christopher L. Morrow
-
Sean Donelan
-
Stephen Sprunk