[c-nsp] QOS advice

[Mihai Tanasescu]

Justin Shore wrote:

> Pete Templin wrote:
>
>> mihai at duras.ro wrote:
>>  
>>
>>> Although there is no congestion present there, the voip solution
>>> integrator has demanded that QOS be present on the networking 
>>> equipments.
>>>     
>>
>>
>> (disclaimer: pet peeve when people are ambiguous)
>>
>> What are you worried about?  You don't need to make any changes to 
>> your configurations.  You already have a QOS policy in place.
>>
>> (yes, your policy is FIFO, but it's there and it provides a 
>> particular quality of service.)
>>
>> If they want _priority queueing of COS 5 traffic_, they should 
>> specify that.
>>   
>
> It could be worse.  They might not want QoS at all.  I sat in a 
> meeting some months ago with an engineer and sales rep from an ADSL2+ 
> solution provider in which the engineer actually proclaimed that QoS 
> was not needed for our network because our links weren't congested.  
> (Double play is the current plan, voice & data, but triple play will 
> happen in a couple years.)  After picking up our collective jaws we 
> threw out a couple simple questions like what would happen if a voice 
> and data packet arrived an interface simultaneously, the type of 
> gimmie questions that would help most technical people realize they 
> said something inaccurate and correct themselves.  Not this engineer.  
> He went on to say that he'd deployed their ADSL2+ solution at numerous 
> SPs and that none of them utilized any QoS.  He also described how at 
> a previous job he deployed a multi-continental network that carried 
> enterprise voice and data traffic and only utilized QoS on one link.  
> Our subtle hints didn't change his stance and neither did us flat out 
> pointing to the inaccuracies in his statement.  This was the same 
> engineer that thought that a SP of our size had no reason to run an 
> IGP and that static routes were sufficient (though their ADSL2+ 
> solution is now being deployed with end-to-end OSPF) and that MPLS was 
> a dieing technology (I guess that's why Cisco has published 16 books 
> on it in the last 7 years).  But I digress.
>
> Justin
>
Heh, I get your point.

I'm just not to happy about having to come up with a QOS solution 
without some logic behind it. We're just doing this because the 
telecomunications company has ran out of ideas why their particular 
setup is not functioning right.
They've measured delay, jitter, bandwidth (for several days now) all 
over the network and everything was good...so now they insist on it 
being a QOS problem.

What would be the best solution regarding resource utilization on C2950, 
C3550, C4500 for some sort of QOS to be implemented ?
I'm quite afraid that in case the traffic on the C3550 gbit links will 
go beyond the present 100Mbps, some packet loss might appear due to the 
CPU utilization for QOS assurance on those links.
Unfortunately I have no lab yet to test the setup and see how it goes.