<div dir="ltr"><div>It's more about protecting voice traffic from unforseen traffic spikes because we have a very large amounts of data transfer.</div><div> </div><div>It isn't like I'm asking the guys to come up with something new and untested.  I'm asking them to implement what we already have in Europe and Asia.</div>
<div> </div><div> </div><div> </div><div> </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 16, 2013 at 1:17 PM,  <span dir="ltr"><<a href="mailto:A.L.M.Buxey@lboro.ac.uk" target="_blank">A.L.M.Buxey@lboro.ac.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
>    Is this a misunderstanding that throwing bandwidth at voice eliminates the<br>
>    need for priorizing voice traffic?  I'm trying to understand why there is<br>
<br>
if you have fast ASICs and enough bandwidth there really isnt that much need<br>
for QoS - and you can check this by performing end to end analysis of jitter<br>
and packet-loss etc - use IPSLA on the links etc to keep an eye on those.<br>
<br>
QoS on L2 isnt the same kettle of fish as on a WAN. ont he WAN its quite easy to<br>
define the matrix required in most cases as its 'prioritise voice'. on the L2<br>
there is so much other stuff that the enterprise needs - you're introducing<br>
'unfair queuing' for all the other traffic that ends up in the scavenger and<br>
best efforts queues.... look at the list archives to see many people burnt<br>
by turning QoS on certain line cards and edge switches - ones that just dont have<br>
the buffers (3560 and 2960s i'm looking at you at this point in the conversation)...<br>
you are having to provide buffer metrics - how many packets to handle/clear in each bucket<br>
and unless you know exactly how all the applications/protocols alive on your network<br>
work...well, you'll soon find out ;-)<br>
<br>
certainly, there are some networks where they have QoS for more than just voice internally<br>
- they have it for some multicast streams and logistic software and DB connections...<br>
<br>
..but there are probably far more people whose network would be better with QoS<br>
turned off totally inside the network.<br>
<br>
(this is the view from a QoS deployer - and I'm still waiting to see caveats lurking<br>
regarding eg wireless APs and their control traffic.....)<br>
<br>
alan<br>
</blockquote></div><br></div>