[c-nsp] qos plan - advice please

[Tony]

Hi Aaron,

As someone else suggested one reason for needing/using QoS is if you are using sub-line-rate links between your core devices.

If you are purchasing a 400Mbps link from a carrier and have it plugged into a 1Gbps interface, then you will need to shape your traffic to 400M to ensure you don't exceed your CIR with the carrier. If your traffic is particularly bursty or you have the potential that it might be, then you will want to have identified your important traffic (eg. usually VoIP type stuff) so that you can ensure it isn't subject to queueing delay by the shaper you have on the interface towards the carrier. You need to be in the position that IF there is anything being discarded or queued then you know what it is, because once it hits the carrier gear, they won't care, it just get discarded down to CIR you have purchased.

Once you get to this point it means that you need to identify/classify the traffic so you can do this. The usual "mark on ingress at the network edge" is often the best approach to this.

If you have a 1G link on a 1G interface which is under-utilised then you will indeed see no real benefit from QoS, assuming of course that you aren't bursting up to the 1G at all, but not seeing this in 5-min averaged traffic.

In regard to testing, much better to test "through" a device, than "to" the same device to ensure you are getting valid results. There are plenty of small/cheap devices around these days (running a *nix OS) that you could easily deploy as remote probes for this kind of testing.


regards,
Tony.





>________________________________
> From: Aaron <aaron1 at gvtc.com>
>To: mark.tinka at seacom.mu; cisco-nsp at puck.nether.net 
>Sent: Saturday, 31 August 2013 3:58 AM
>Subject: Re: [c-nsp] qos plan - advice please
> 
>
>Thanks, taking several steps back, here's a question please for the
>group....
>
>Why qos?  Does it do any good IF links aren't congested?  In other words, if
>I don't have congestion, is there a reason for it?  ...meaning that if I can
>simply add fatter pipes (go from 1 gig to 2 gig etherchannel, or from 10 gig
>to 20 gig etherchannel) then does fatter pipe solve all my qos problems?
>Latency, delay, jitter, bandwidth needs solved with fatter pipes?
>
>In other words, if I have an sla requirement to provide one-way 5 ms delay
>(nothing more or I'm in violation of sla), AND my interconnections
>throughout my network are NOT congested (utilized at or above line rate) AND
>I'm seeing ip sla probes reporting 200 ms latency will qos solve this?
>
>Aaron
>
>
>-----Original Message-----
>From: Mark Tinka [mailto:mark.tinka at seacom.mu] 
>Sent: Friday, August 30, 2013 11:20 AM
>To: cisco-nsp at puck.nether.net
>Cc: Aaron; 'Robert Blayzor'
>Subject: Re: [c-nsp] qos plan - advice please
>
>On Friday, August 30, 2013 05:41:38 PM Aaron wrote:
>
>> Thanks Robert,
>> 
>> - (15) asr9k's in core
>> - (40 or 50) asr901's and me3600's
>> 
>> That pretty much covers my mpls cloud.... I'm running single area ospf 
>> on all those, and mpls on all, and so all of them (9k's, 901's and 
>> me's) act as a mix of p's and pe's
>
>I've always supported DiffServ. I've found using RSVP to signal admission
>control to be otherwise heavy (there was a reason it never took off in the
>first place, despite how noble the idea was).
>
>But, your network, your choice :-).
>
>Mark.
>
>