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 <[email protected]> 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/[email protected]/message/7UNB5XVLC5Q5Y42KUSIKSVCWI4PJ75J4/ -- ++ytti _______________________________________________ NANOG mailing list https://lists.nanog.org/archives/list/[email protected]/message/SUWSGN2WJUXXXLGQ5KCIAGJXZVPJUO4I/
