[j-nsp] Use cases for IntServ in MPLS backbones

[James Bensley]

> On 1/Oct/18 12:16, adamv0025 at netconsultings.com wrote:
>
> > Hi folks,

Hi Adam,

On Mon, 1 Oct 2018 at 12:00, Mark Tinka <mark.tinka at seacom.mu> wrote:
>
> So we don't do any label signaling via RSVP-TE at all.
>
> We use DSCP, but really only for on-net traffic.
>
> Off-net traffic (like the Internet) is really treated as best-effort.
> You can't prioritize what you can't control.

Yeah so not already using RSVP means that we're not going to deploy it
just to deploy an IntServ QoS model. We also use DSCP and scrub it off
of dirty Internet packets.

Like with many things, it depends on your requirements. Having worked
for managed WAN providers where you have a infrastructure shared
amongst multiple customers / stakeholders and provide WAN connectivity
with over the top services like Internet and VoIP, QoS is a product
most customers expect. In this scenario you typically have a set of
queues and customer can access either all of them or a sub-set for a
cost. In a former life we had up-to 8 classes for customers which you
can simplify in your core using pipe mode or short pipe QoS models. We
could offer multiple QoS levels to customers, but simplify the classes
down to like 3-4 in the core, and without any need for RSVP. I feel
this is a good balance between complexity/simplicity and scalability.
If you don't have multiple stakeholders then IntServ becomes more
appealing due to the granularity on offer, but in the shared
infrastructure scenario my experience is that mapping multiple
customer queues down to a fewer core queues helps to protect the
control plane and LLQ traffic in a simply way that covered all stake
holders, and no need for the additional signalling complexity that
RSVP brings.

Cheers,
James.