[j-nsp] QoS when there is no congestion

[Andrey Khomyakov]

"My opinion on QoS for networks with low bandwidth is to always implement
it." Most definitely. Scheduled drops are always better than tail drops.
As for microbursts, I can't say I'm very knowledgeable about what that is.
I'm guessing that we are talking about extremely brief periods when egress
rate exceeds line rate, but not long enough to get registered on the stats
collectors that we all look at. In this case, I don't know if QoS has a
chance to do any work here.


--Andrey

On Mon, Nov 14, 2016 at 8:37 AM, Eric Van Tol <eric at atlantech.net> wrote:

> > Yeah YMMV indeed, as your approach works only in one of the three cases
> > below:
> > 1) Your network is not connected to the Internet.
> > 1) Your network is connected to the Internet, but all traffic on your
> > network is best effort.
> > 3) Your network is connected to the Internet, but the sum of traffic that
> > can ingress your network from the Internet is less than the capacity of
> the
> > smallest link on your network.
>
> My opinion on QoS for networks with low bandwidth is to always implement
> it. It's really not that difficult and you never know when microbursts
> could be affecting things. Believe me, even if your upstream link is a
> 1Gb/s circuit, and your outbound traffic is less than 10Mb/s, you can still
> have drops due to microbursts.
>
> Voice and video, depending on your use of them, are normally very
> important and very sensitive to drops/delays. It will never cost you
> anything (besides time) to learn to implement some simple QoS policies,
> however, if you have customers who complain about bad voice/video quality,
> it will cost you your reputation and possibly revenue when said customers
> cancel their contracts because of a service you cannot reliably provide.
>
> -evt
> _______________________________________________
> juniper-nsp mailing list juniper-nsp at puck.nether.net
> https://puck.nether.net/mailman/listinfo/juniper-nsp
>