[cisco-voip] QoS and network guys

[Erick Wellnitz]

It's more about protecting voice traffic from unforseen traffic spikes
because we have a very large amounts of data transfer.

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.






On Mon, Sep 16, 2013 at 1:17 PM, <A.L.M.Buxey at lboro.ac.uk> wrote:

> Hi,
>
> >    Is this a misunderstanding that throwing bandwidth at voice
> eliminates the
> >    need for priorizing voice traffic?  I'm trying to understand why
> there is
>
> if you have fast ASICs and enough bandwidth there really isnt that much
> need
> for QoS - and you can check this by performing end to end analysis of
> jitter
> and packet-loss etc - use IPSLA on the links etc to keep an eye on those.
>
> QoS on L2 isnt the same kettle of fish as on a WAN. ont he WAN its quite
> easy to
> define the matrix required in most cases as its 'prioritise voice'. on the
> L2
> there is so much other stuff that the enterprise needs - you're introducing
> 'unfair queuing' for all the other traffic that ends up in the scavenger
> and
> best efforts queues.... look at the list archives to see many people burnt
> by turning QoS on certain line cards and edge switches - ones that just
> dont have
> the buffers (3560 and 2960s i'm looking at you at this point in the
> conversation)...
> you are having to provide buffer metrics - how many packets to
> handle/clear in each bucket
> and unless you know exactly how all the applications/protocols alive on
> your network
> work...well, you'll soon find out ;-)
>
> certainly, there are some networks where they have QoS for more than just
> voice internally
> - they have it for some multicast streams and logistic software and DB
> connections...
>
> ..but there are probably far more people whose network would be better
> with QoS
> turned off totally inside the network.
>
> (this is the view from a QoS deployer - and I'm still waiting to see
> caveats lurking
> regarding eg wireless APs and their control traffic.....)
>
> alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20130916/92ea270e/attachment.html>