@Giuseppe Larosa wrote:
you should implement QoS on all switches in the path as suggested by @Joseph W. Doherty .
I don't believe I actually explicitly suggested that, although I may have inadvertently implied that. ; )
As to whether QoS is actually needs to be configured depends on whether it actually is also needed and can deliver the results needed. I.e. often it's not actually needed to be configured end-to-end; still, though, it's very advisable to do so.
That said, the "book" suggests that it should be, and the "book" recommendation is good because only with QoS configured end-to-end can you provide end-to-end service guarantees. Also, networks, and their usage, can change. If you don't have end-to-end QoS, what works fine today, might not work well tomorrow.
So am I now, recommending end-to-end QoS? Well . . .
QoS has its pros and cons. Cons include, QoS has its own "care and feeding" requirements. Further, depending on your needs, a one size fits all QoS model might not work for you.
So, what I actually often recommend with QoS, is a case by case analysis of its RoI. If some cases, usually like WANs, QoS often has a great RoI. In some other cases, usually like LANs, other approaches might have a better RoI.
Also, understand, you can mix and match. For example, a complex QoS model for WAN interfaces, and a simple QoS model for LAN interfaces.
@Giuseppe Larosa wrote:
Ideally , you should be able to call also without QoS applied if the network load is low but you may have production data traffic and without QoS you cannot avoid issues like big data packets being served = put on the wire before the small delay sensitive VOIP packets. This can create delay variance = jitter that impairs voice quality.
There's much truth in the forgoing, but "low" traffic levels don't guarantee VoIP success and conversely "high" traffic level don't guarantee VoIP problems. Also "big" data packets aren't, in themselves, even jumbos, necessarily (or in modern networks often) adverse to "small" VoIP packets.
Although often traffic utilization level and/or packets sizes seem to go hand-in-hand with VoIP issues, there are other variables that matter that are often not considered.
Simple example:
On a 64 Kbps link, it takes 187.5 ms to serialize a single 1518 byte Ethernet frame. Consider, the usual maximum bound for VoIP latency is 250 ms, and 150 ms or under is recommended, 187.5 ms isn't particularly good. This is an example of the "big" packet issue, Giuseppe mentions.
For low bandwidth interfaces, Cisco had/has a Link Fragmentation and Interleaving (LFI) feature.
So if 1500 is borderline bad, a 9000 byte jumbo must be out of bounds, correct?
Yes it would be on a 64 Kbps link, but what if used on a gig link?
Then its serialization delay is 72 Āµs. As VoIP latency tolerance hasn't changed, 72 Āµs isn't much of a concern.
What impacts VoIP quality is packet loss, overall latency and (as mentioned by Giuseppe) jitter, but problem causes are a bit more than just packet sizes (which is a factor) or average load utilizations, the latter usually measured in lots of seconds to minutes. With VoIP, we need to understand, and allow for, "things" happening in milliseconds.
In other replies, I've remarked that Cisco's QoS information has greatly improved, over the years.
In Cisco's Technote, Troubleshoot Output Drops on Catalyst 9000 Switches, refer to the last section which shows how drop issues cannot be seen even at 1 second intervals, but can be seen at 1 ms intervals.
