<div dir="ltr"><div>No argument that being hesitant and very cautious is a good thing.  </div><div> </div><div>I would add that it is also important on access ports where the phone and PC share a connection AND the user is a heavy bandwidth user.  </div>
<div> </div><div>I do appreciate all of the insight.  It is very helpful to understand other people's view on QoS.</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 16, 2013 at 4:46 PM, Nick Matthews <span dir="ltr"><<a href="mailto:matthnick@gmail.com" target="_blank">matthnick@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div><div><div>I think it's fairly simple - the value of L2 QoS isn't as high as WAN.<br>
<br></div>1. L2 QoS is at least an order of magnitude more difficult. Buffers, DSCP/COS concerns, hardware dependent, dozens of lines of configuration (see AutoQoS outputs) potentially.<br>

</div>2. L2 QoS really comes into play during loops, viruses, or oversubscribed trunk ports. These aren't that common.<br></div>3. It's quite easy to mess up or cause problems. If you forget to trust a port, everything is 0 on many platforms. Sometimes QoS causes odd issues on ports that would otherwise be fine. For example the default queues with AutoQoS can cause bandwidth problems because of a more limited queue for BE traffic compared to the default.<br>


<br></div>It's best practice and you should do it, because that's one less thing that can cause voice quality problems. But there are valid reasons to being hesitant to L2 QoS. I think as more video is deployed it will become more important, since video bandwidths can start taxing uplinks and ports more easily. And at that point the configuration isn't much different.<br>


<br></div>-nick<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Sep 16, 2013 at 3:33 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 style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid" class="gmail_quote">Hi,<br>
<div><br>
>    It's more about protecting voice traffic from unforseen traffic spikes<br>
>    because we have a very large amounts of data transfer.<br>
<br>
</div>true - though I've tested VoIP across a 3:1 contended 1G pipe and whilst there<br>
was an interesting delay to the call (notable because both handsets were in the same<br>
room rather than other end of country) there was no jitter...so the call was fine.<br>
no bubbling, gurgling, squeaks etc etc - I guess it depends on what TYPE of transfer<br>
is going on. I'm sure some nice 'very efficient' P2P protocol would do more damage<br>
than pure HTTP/FTP which will do its nice window scaling and fallback.<br>
<div><br>
>    It isn't like I'm asking the guys to come up with something new and<br>
>    untested.  I'm asking them to implement what we already have in Europe and<br>
>    Asia.<br>
<br>
</div>well then. no excuse :-)<br>
<div><div><br>
alan<br>
_______________________________________________<br>
cisco-voip mailing list<br>
<a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br>
<a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>
</div></div></blockquote></div><br></div>
</blockquote></div><br></div>