[j-nsp] Juniper MPC2E-3D-NG-R-B vs MPC2E-3D-R-B

[Pavel Lunin]

Andrey Kostin wrote:

>
> HQoS is needed for subscriber aggregation, exactly for the case that is
> discussed in another thread "Juniper buffer float".



This is how Juniper and other vendors present it. But it's very
questionable if you really need a dedicated set of queues per subscriber
interface.

Even with triple-play (which is dying in some countries and has never
really born in others) you can cope with policers instead of shapers on the
DSI level and a physical interface queues to control the ratio between
Internet/Voice/TV/etc. It just won't be that much of copy-pasting of the
"official" vendor's guides, but it's definitely doable if all subscribers
on a given physical interface share a fixed set of predefined services.

For pure Internet, of course you can put customer packets in a buffer, than
wait a bit, than drop it with the fancy WRED algorithm, but simply dropping
with a policer is a much cheaper way to slow down the customer's TCP (or
QUIC or torrent or whatever).

The case where per unit queueing is really inevitable is rather business
VPN with multiple traffic classes per customer and different commitment
ratios for different customers, sharing the same physical port. Or
sometimes you might want to share the same port for B2B and B2C
subscribers. But... It really depends if your marketing knows how to get
money out of this. Honestly speaking, I doubt that they do, but traditional
business telco giants must have such services in their portfolios because
they just must. B2B people love to talk about QoS, you know. You can't just
tell your customer "we drop your packets" if you wear a suit with a tie.

On the other hand, it's also a matter of price of those cards. With
sufficient volume, the difference between -Q and non-Q might probably be
negligible. And the fact that it's "officially" documented and supported by
JTAC might also change something.

However, in my experience, people tend to buy Q-cards rather because of
FUD, because someone has said them to do so, or because it's public money
and nobody cares.

But no matter how much it costs in CAPEX, HQoS is still complex as hell,
even if you have money to pay those cards. So only use it if you really
know what you are doing, otherwise it will make more harm than good (I have
examples, if you wish).

--
Pavel