Re: Cisco PPP DS-3 limitations - 42.9Mbpbs?
The place where QOS always made sense to me is not where they want to put it (and it's very apropos to the current conversation.) Specifically, at the customer edge, as opposed to the provider core. Some folks are always going to have higher bandwidth needs than money. We can complain all we want about how, in a perfect world, everybody should buy more bandwidth before queue delay and congestion are a problem, but in the end, Generic Office X's communication budget is probably for a single T1, which can either run VOIP or be channelized into nxDS0 for phone and 24-nxDS0 for data. In either case, it doesn't take much legitimate traffic before you start seeing problems, especially if you're doing VOIP, video- conferencing, web serving, and Bob is sitting in his office listening streaming video and browsing alt.sex.toasters. And sure, it would be nice if people were responsible and didn't use bandwidth frivolously, but we're in the real world, and when people won't behave, the system should have the option of trying to do the right thing. So, at the edge, you prioritize voice over streaming media over web over news over mail, and everything behaves acceptably. *That* is where QOS really shines. For some reason, though, nobody wants to sell it there. Must be more profitable to sell 'em a bigger line. -Dave On 2/20/2002 at 14:11:01 -0800, Tony Rall said:
On Wednesday, 2002/02/20 at 09:08 PST, Randy Bush <randy@psg.com> wrote:
[0] - corollary: qos mechanisims decide which packets to drop. but isps are paid not to drop any packets.
Exactly. I've been saying this to vendors for the last few years, as they try to push their QOS mechanisms on me.
I'm not in the business of trying to engineer some optimum packet discard strategy. I would rather spend my time and money trying to minimize the drop percentage. (I haven't been tested yet with the task of trying to minimize or standardize latency for traffic like VOIP - might change my tune if I was dealing with that.)
Tony Rall
That is exactly right. The whole point of QoS is to optimize the network. It does not do much for the customer if we let him saturate a low speed link with nonconforming traffic and then drop it at the core. It is best to drop the nonconforming traffic at the customer end or at very least the service providers edge router. The sooner you get the nonconforming traffic off the network, the better the entire network performs. One problem with QoS policy enforcement is that it kind of gives the customer a false sense of capacity. I have seen customers that prioritize certain traffic and then complain because of high latency and drops on the other traffic. There is something to be said for engineering capacity to provide full performance for all traffic types. I personally engineer backbones to provide no drops and low latency for all traffic period. QoS helps a customer control his usage but the backbone should be able to provide good performance for all traffic classes otherwise you are punishing the high bandwidth customer that pay for pipes big enough for all of their needs. Steve
-----Original Message----- From: owner-nanog@merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Dave Israel Sent: Wednesday, February 20, 2002 4:32 PM To: Tony Rall Cc: nanog@merit.edu Subject: Re: Cisco PPP DS-3 limitations - 42.9Mbpbs?
The place where QOS always made sense to me is not where they want to put it (and it's very apropos to the current conversation.) Specifically, at the customer edge, as opposed to the provider core.
Some folks are always going to have higher bandwidth needs than money. We can complain all we want about how, in a perfect world, everybody should buy more bandwidth before queue delay and congestion are a problem, but in the end, Generic Office X's communication budget is probably for a single T1, which can either run VOIP or be channelized into nxDS0 for phone and 24-nxDS0 for data. In either case, it doesn't take much legitimate traffic before you start seeing problems, especially if you're doing VOIP, video- conferencing, web serving, and Bob is sitting in his office listening streaming video and browsing alt.sex.toasters.
And sure, it would be nice if people were responsible and didn't use bandwidth frivolously, but we're in the real world, and when people won't behave, the system should have the option of trying to do the right thing. So, at the edge, you prioritize voice over streaming media over web over news over mail, and everything behaves acceptably. *That* is where QOS really shines. For some reason, though, nobody wants to sell it there. Must be more profitable to sell 'em a bigger line.
-Dave
On 2/20/2002 at 14:11:01 -0800, Tony Rall said:
On Wednesday, 2002/02/20 at 09:08 PST, Randy Bush <randy@psg.com> wrote:
[0] - corollary: qos mechanisims decide which packets to
are paid not to drop any packets.
Exactly. I've been saying this to vendors for the last few years, as they try to push their QOS mechanisms on me.
I'm not in the business of trying to engineer some optimum
drop. but isps packet discard
strategy. I would rather spend my time and money trying to minimize the drop percentage. (I haven't been tested yet with the task of trying to minimize or standardize latency for traffic like VOIP - might change my tune if I was dealing with that.)
Tony Rall
participants (2)
-
Dave Israel -
Steve Naslund