[cisco-voip] QoS and network guys
Erick Wellnitz
ewellnitzvoip at gmail.com
Tue Sep 17 10:18:25 EDT 2013
No argument that being hesitant and very cautious is a good thing.
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.
I do appreciate all of the insight. It is very helpful to understand other
people's view on QoS.
On Mon, Sep 16, 2013 at 4:46 PM, Nick Matthews <matthnick at gmail.com> wrote:
> I think it's fairly simple - the value of L2 QoS isn't as high as WAN.
>
> 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.
> 2. L2 QoS really comes into play during loops, viruses, or oversubscribed
> trunk ports. These aren't that common.
> 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.
>
> 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.
>
> -nick
>
>
> On Mon, Sep 16, 2013 at 3:33 PM, <A.L.M.Buxey at lboro.ac.uk> wrote:
>
>> Hi,
>>
>> > It's more about protecting voice traffic from unforseen traffic
>> spikes
>> > because we have a very large amounts of data transfer.
>>
>> true - though I've tested VoIP across a 3:1 contended 1G pipe and whilst
>> there
>> was an interesting delay to the call (notable because both handsets were
>> in the same
>> room rather than other end of country) there was no jitter...so the call
>> was fine.
>> no bubbling, gurgling, squeaks etc etc - I guess it depends on what TYPE
>> of transfer
>> is going on. I'm sure some nice 'very efficient' P2P protocol would do
>> more damage
>> than pure HTTP/FTP which will do its nice window scaling and fallback.
>>
>> > 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.
>>
>> well then. no excuse :-)
>>
>> alan
>> _______________________________________________
>> cisco-voip mailing list
>> cisco-voip at puck.nether.net
>> https://puck.nether.net/mailman/listinfo/cisco-voip
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/cisco-voip/attachments/20130917/874a0011/attachment.html>
More information about the cisco-voip
mailing list