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

[Mark Tinka]

On 2/Oct/18 12:10, Saku Ytti wrote:

> Dropped by who? I as an Internet user would prefer my DSCP information
> to traverse internet, I do not ask it to be honoured.

Dropped by the customer's network itself.

There was something in their firewall that was dropping packets that had
a non-zero value. They couldn't figure it out, and to make matters
worse, it happened only if traffic was coming from only some peering
point, some transit networks, and some other on-net edge customers.

Since we cannot guarantee the end-to-end quality of off-net traffic, it
does not make sense to have any DSCP values for Internet traffic other
than 0. Because even though I might not remark it, I can't guarantee
that my peers, transit providers or other customers won't.


> If customer has problems with DSCP, then of course they can nullify it
> in their network, or you can even sell it as service to them. But to
> nullify it for everyone seems quite big hammer, unless of course in
> your particular deployment it would be technically not possible to
> retain them.

In theory, it would be nice that random DSCP values in Internet-bound
packets are honoured. In practice, we have not had any customers who
have asked for this, or needed to use it, or complained when we didn't
support it.

The work that would be required to do this selectively for the large and
diverse customer-base does not make sense.

If you are a large network (such as yourselves, Saku) where it's very
likely that the majority your customers are talking to each other
directly across your backbone, then I could see the case. But when you
have customers transiting multiple unique networks before they can talk
to each other or to servers, there is really no way you can guarantee
that DSCP=1 from source will remain DSCP=1 at destination.

Mark.