[j-nsp] QoS when there is no congestion

[Andrey Khomyakov]

Sure, you could mitigate some of that with enforcing w/ever at the
boundaries, but hopefully you are starting to see how a simple QoS policy
design on a single node is blowing up into managing hundreds/thousands of
ports and making sure you trust your VoIP telephone, but not the
workstation behind it and so on. Then you have to make sure that all your
cross connects, uplinks, etc. either trust your tags or inspect each packet
and rewrite the tag (DSCP). Now you are managing QoS policies on every
intermediary device if you decided to make uplink not trusted for w/ever
reason.
So in case of the single router that you want to apply your egress QoS onto
if you chose not to manage your QoS downstream with trusted uplinks,
inspection at boundary, etc, you’d have to classify on some other than DSCP
info on ingress to your router and then make the egress decision. And thus,
my original point is shown that you’ll be editing that policy every time
your traffic patterns change or new application that needs a certain class
of service is deployed. As usual, YMMV, but that’s my experience with QoS.
Every time I tried it, it turned out to be more headache than just buying
more BW.

Hope this helps
Andrey

On Thursday, November 10, 2016, Aaron <aaron1 at gvtc.com> wrote:
> Thanks Andrey,   you mentioned ... "You could end up in a DoS situation
> where some rouge source send 1gbps worth of packets matching your priority
> class"
>
> Is this where a properly controlled QoS Trust Boundary comes into
> play?...like not trusting what ingresses that boundary, classifying and
> remarking... so that queue hijack can't occur ?
>
> - Aaron
>
>
>
>

-- 
Sent from Gmail Mobile