Re: DSCP-45 - from Zayo, Hurricane Electric, Lumen

[Saku Ytti via NANOG <nanog () lists nanog org>]

The draft provided seems to have a different message than the email.

The draft provided seems to call discriminatory behaviour for BE and
DSCP-45. You seem to request non-discriminatory behaviour, just leave
the bits alone.

I fully agree with your request. I think the draft is proposing a
logical fallacy and then explicitly telling us there is no logical
fallacy. The logical fallacy being if you discriminate between DSCP
you can abuse it, if you cannot abuse it, there is no discrimination.
Any different behaviour in shared link between BE and DSCP-45 and you
can put bits on your packet which shows superior performance, until
superior performance goes away. Heck, I abuse this, because by default
I get 5% dedicated bandwidth on Juniper networks that don't have
explicit QoS config (that's a lot of them).

Only thing that works, is what you are asking, just pass DSCP-45 as
is, treat it exactly the same as BE, just retain the bits and
discriminate on non-shared link.

DSCP-45 can only achieve discrimination on the last mile, non-shared
interface. If iPhone upgrade puts their packets to DSCP-45, then
people will name and shame Apple until their COD gaming works again.

Generally speaking, if people at all can, they should never touch
customer bits, be it DSCP, BGP communities, anything, just because you
don't know the utility, doesn't mean there isn't. For DSCP the
solution is fairly easy, always carry additional header, VLAN, MPLS
(expnull) or IP tunnel where you put your own QoS and tunnel DSCP
unchanged.

On Tue, 27 Jan 2026 at 18:03, Livingood, Jason via NANOG
<nanog () lists nanog org> wrote:
> In support of IETF L4S and NQB dual queue low latency standards, Comcast (and other networks) have been actively 
> deploying this technology. L4S uses ECN marks and, since ECN is rarely modified in packet headers, this generally 
> works find across domain boundaries. The more challenging one is NQB, since this is predicated on the DSCP-45 mark 
> crossing domain boundaries - and as I think we all know, network domains all implement DSCP differently and so tend 
> to remark DSCP on ingress.
>
> Thus, to support NQB, a network will allow DSCP-45 at ingress and classify the traffic as best effort (like default 
> internet traffic). Comcast has done so and we have >10M homes with dual queue (aka Low Latency DOCSIS, a DOCSIS 
> implementation of L4S and NQB).
>
> The volume of DSCP-45 traffic is beginning to grow, so we have started to look at traffic sources as we quantify 
> improvements in application quality of experience (e.g., lower loaded latency and lower jitter). Apart from the 
> expected sources we have observed double digit Mbps (far <1% of DSCP-45 volume) - from Zayo, Hurricane Electric, and 
> Lumen.
>
> If you run one of those networks, you may want to look at the source of DSCP-45 traffic to ensure your DSCP policies 
> are squared away. Feel free to ping me for more information if you have any questions.
>
> Thanks
> Jason
>
>
> For more info:
>
>   1.
> TSV NQB draft is in the publishing queue (https://datatracker.ietf.org/doc/draft-ietf-tsvwg-nqb/).
>   2.
> In support of this, IANA have entered DSCP code point 45 into their registry 
> (https://www.iana.org/assignments/dscp-registry/dscp-registry.xhtml).
>
> _______________________________________________
> NANOG mailing list
> https://lists.nanog.org/archives/list/nanog () lists nanog org/message/7UNB5XVLC5Q5Y42KUSIKSVCWI4PJ75J4/



-- 
  ++ytti
_______________________________________________
NANOG mailing list 
https://lists.nanog.org/archives/list/nanog () lists nanog org/message/SUWSGN2WJUXXXLGQ5KCIAGJXZVPJUO4I/