At 03:09 AM 12/18/2001, Shane Kerr wrote:
>Now, I'm not a router guy, so this may not matter in the Real World(tm),
>but QoS isn't necessarily something you can ignore just by making sure
>your network is reliable. Even if no packets ever get dropped, you may
>still exceed the jitter requirements of a phone call, making it
>impossible to hear the person at the other end of the phone. In such a
>case, using "drop" as a synonym for "defer" may be the right thing to
>do: the better of several unhappy alternatives.
yes, that's part. Also, in Enterprise networks, we find a lot of folks who
want to ensure that this crowd gets a certain amount of bandwidth at least
or at most; for example, Telecom Danmark runs a network that connects the
schools (K-PhD) plus their teachers, and tries to ensure that the teachers
get at least a certain capacity, kids accessing the libraries and other
sanctioned places get at least a certain capacity, and folks surfing the
web get at most a certain capacity. When you say things like that, you are
not saying "provide so much that I can't drop"; you are saying "this is
what you get, use it well". To use it well winds up meaning that you want
to interact well with the TCP in the sender so that it performs well.
I think your problem, Randy, is that you work in a certain part of the
network. Notice I have never particularly argued that your part of the
network has different requirements than you think it has; I suspect you
understand your part of the network pretty well. But in your part of the
network, bandwidth is your commodity and your business, and you use enough
of it to justify laying your own fiber (which you don't), and in lease/swap
negotiations you can use that fact to barter the price down. So for you,
bandwidth is relatively cheap, and you can solve anything else by making
the statistics favor it.
You then sell your bandwidth to others, but you don't give it to them at
cost. Their objectives don't have to do with building a network; their
objectives have to do with building tractors, reading books, or something
else. To them, the network is not a commodity, it is a cost, and they are
charged with delivering an application (voice, ERP, web, whatever) with a
certain response time, service rate, or whatever, and within the same
budget they did it last year. They see tools for managing their costs while
providing tailored performance to specific applications as a benefit.
When I speak on QoS, I get people coming out of the woodwork that say "I
don't understand why Cisco is so convinced that bandwidth is free and all
you need to do is have an infinite amount of it; it sure isn't free to me.
I'm glad to finally hear someone who has a clue that we're struggling to
reduce costs out here." I have heard your arguments about the relative cost
of this and that, and I'll be the first to agree with you that if you want
to deploy QoS you have to make some hard choices, and you'd best do so
intelligently. But in those quarters folks tell me that the money is better
spent, and that it is in fact less.
Where I wind up scratching my head is not that you don't want QoS
technologies, but that you assume that anyone who wants to work on it or
use it is dense. I should think you'd give them as much grace as they give you.
>But if your customer pays you not to drop packets, then that's what you
>should do. ;)
hence ECN. Yes, I agree.
This archive was generated by hypermail 2b29 : Mon Aug 04 2003 - 04:10:03 EDT