Regarding QoS, we have two modes: shaping or policing. The policing drops packets while shaping put the packets in buffer.

Shaping seems to be the better solution in a general ways, so, why use policing ?

For the real time application and regarding the quality (voice, visio, etc), packets delayed are worst than packets dropped ? In which others examples the policing should be preferred ?


There are cases where the given platform cannot shape at all or not in the required direction. On the (Cisco) platforms I have come across, ingress QoS is usually able to police, but not shape, while egress QoS can queue/shape and/or police.

Shaping/Queuing requires buffer memory per port (which can be a very limited ressource on some platforms), and can lead to delay and jitter as soon as those (egress) buffers start to fill up.

There are cases where varying and volatile RTTs (read: jitter) hurt the application more than a few lost packets. Also, not all TCP congestion avoidance algorithms are equal - some only consider packets lost, others take the RTT/jitter into account.

I found https://blog.ipspace.net/2016/09/policing-or-shaping-it-depends.html and http://packetlife.net/blog/2008/jul/30/policing-versus-shaping/ to show the differences pretty clearly.

In short: Policing is needed in two cases:

  • ingress policing, e.g. to prevent the "clever" students on the VoIP enabled campus to pump more than, let's say, 250kbit/s of EF/DSCP46 traffic per port into your network.
  • egress policing for applications that do not like jitter - mostly RTP streams for voice, but also things like PTP (Precision Time Protocol).
| improve this answer | |
  • Even within a given vendor (ex: Cisco) capabilities for input vs output marking and QoS enforcement vary tremendously based on platform type and application. Policing is relatively cheap to implement in hardware (and thus quite common) while true shaping is expensive - thus the substantially lower density and higher prices for ports on routers versus ports on switches. Similarly there is often a 2X-4X per-port price difference for different classes of interfaces of the same speed in some router lines (ex: ASR9K) reflecting resources for features like fancy queueing. – rnxrx Jun 19 '18 at 3:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.