Thanks Jason, this is a very helpful and grounded perspective. What you describe matches what we are observing operationally across many networks: once traffic crosses an administrative boundary, DSCP is no longer a reliable signal for scheduling, and treating ingress traffic as Best Effort while preserving the DSCP field itself is the only approach that scales without creating implicit trust or privilege escalation. The point about NQB is particularly important. Its emergence reinforces the idea that cross-domain coordination should focus on congestion behavior rather than priority. Carrying NQB as Best Effort, without expedited treatment, feels like a pragmatic and neutrality-friendly evolution compared to legacy DiffServ assumptions. Your note on ECN is also well taken. Ensuring that ECT and CE markings are preserved across peer boundaries, and that congestion can be signaled rather than hidden, is likely far more valuable in practice than attempting to honor priority markings end-to-end. From a MANRS standpoint, this discussion seems to converge on a clear set of principles: explicit trust boundaries, decoupling packet markings from local scheduling decisions, and protecting infrastructure while maintaining semantic transparency. That combination provides neutrality, stability, and operational safety without requiring inter-domain agreements on queue semantics. Thanks for helping anchor the discussion in real-world practice. Have a good one! Paolo Caparrelli GOLINE SA Da: Livingood, Jason <Jason_Livingood@comcast.com> Inviato: giovedì, 5 febbraio 2026 16:49 A: Caparrelli Paolo <paolo.caparrelli@goline.ch>; Martin Passard <martin.passard@ielo.net>; manrs-community@elists.manrs.org Cc: Tech IELO <tech@ielo.net> Oggetto: Re: Best practice over DSCP and priority as an ISP and IX and QOS in General Questa email arriva da un mittente insolito. Assicurati che sia qualcuno di cui ti fidi. General practice today is on packet ingress that the receiving network will mark all traffic as CS1 for Best Effort (DSCP-0), so no special prioritized per hop behavior, because other network use all sort of different diffserv classes. The only mark networks are beginning to honor across domain boundaries would be DSCP-45 for Non-Queue-Building (NQB) per hop behavior (just added to the IANA database). That would also be carried Best Effort, not as expedited or assured. I doubt you are touching the ECN header but that is worth checking. You want to be sure that ECT(0), ECT(1), and CE marks in the head pass across the peer boundary. You get extra credit if you hop is capable of adding a CE mark if that hop is congested. Jason From: Caparrelli Paolo via MANRS Community <manrs-community@elists.manrs.org <mailto:manrs-community@elists.manrs.org> > Date: Thursday, February 5, 2026 at 09:37 To: Martin Passard <martin.passard@ielo.net <mailto:martin.passard@ielo.net>
, manrs-community@elists.manrs.org <mailto:manrs-community@elists.manrs.org> <manrs-community@elists.manrs.org <mailto:manrs-community@elists.manrs.org> > Cc: Tech IELO <tech@ielo.net <mailto:tech@ielo.net> > Subject: [EXTERNAL] [manrs-community] R: Best practice over DSCP and priority as an ISP and IX and QOS in General
Ciao Martin, Great topic. This is one of those operational questions that doesn't get nearly enough public discussion, and I'm glad you're bringing it to MANRS. I'll share our perspective as a managed security and network services provider operating across enterprise environments, but the principles apply broadly to any transit or access network. The core issue, stated plainly The real problem isn't DSCP itself. It's the conflation of two fundamentally different things: the DSCP value in the IP header, which is a semantic label that travels with the packet, and the local scheduling decision your equipment makes based on that label, which is a per-hop behavior entirely within your domain. These are decoupled by design in DiffServ (RFC 2474/2475), and keeping them decoupled in your implementation is the key to solving this cleanly. Most of the confusion, including in your team I suspect, comes from the fact that vendor defaults (Cisco in particular) tightly couple ingress DSCP to internal queue assignment without any explicit policy. This makes it feel like respecting the DSCP field and honoring it in your scheduler are the same action. They are not. What we consider best practice The approach that is both operationally sound and neutral starts with establishing an explicit trust boundary at every customer-facing interface. This is non-negotiable. On untrusted interfaces (customer, transit customer) you decouple the DSCP-to-queue mapping. The DSCP field in the packet is preserved, you don't rewrite it, but your internal scheduling ignores or remaps it to a non-priority forwarding class. On IOS-XR, this means using a policy-map ingress with `set qos-group` or `set traffic-class` to override the internal classification without touching the DSCP bits. On Juniper MX, you'd set the forwarding-class via a classifier applied on the interface while keeping the rewrite-rules separate or absent entirely. The DSCP value egresses your network untouched. From there, the critical piece is reserving your strict-priority queues, typically the top one or two, exclusively for locally-originated control plane traffic. BGP, OSPF/ISIS, LDP, BFD, RSVP-TE, LACP: these should be the only traffic in those queues, and they should be marked by your own routers, not by anything an external party sends you. No transit packet, regardless of its DSCP value, should ever land in those queues. This isn't really a QoS policy decision. It's infrastructure protection, same category as CoPP. For customer traffic below those protected queues, you can offer a few scheduling classes with policing at ingress using committed and excess rates. If a customer has a contractual SLA for QoS-marked traffic, say managed VoIP with EF marking, you reclassify it into the appropriate internal class based on your own trust policy, not blindly based on what they mark. If there's no SLA, everything goes into the default class regardless of DSCP. One thing I'd strongly recommend is to avoid rewriting DSCP to zero as a blanket policy if you can. In a multi-domain path, the DSCP value may carry end-to-end semantic intent between the customer's endpoints. A VoIP provider transiting your network expects EF to survive so the far-end can act on it. Zeroing it is a destructive action that removes information you don't own. It's the easy approach, and many large operators do it, but it's not the right approach if you care about being genuinely neutral. The correct alternative is to simply not let that marking influence your scheduling while preserving the bits in the header. On the neutrality question I think there's a common misconception worth addressing here. Network neutrality does not mean every packet must receive identical per-hop treatment regardless of its headers. It means you don't discriminate based on content, application, or destination. Protecting your control plane from externally-marked CS6/CS7 traffic is not a neutrality violation any more than applying CoPP or uRPF is. It's basic infrastructure hygiene. The distinction matters: you're not degrading the customer's traffic by putting it in the default queue. You're refusing to elevate it into a queue it has no business being in. The customer still gets the service they're paying for, best-effort transit at the contracted rate. They don't get to unilaterally promote themselves into your signaling queue. That's not a right, it's an exploit. On IXPs Agreed this deserves separate treatment. An IXP operates at L2, so DSCP handling is mostly irrelevant to the fabric itself, but the peering routers connected to the IXP are where the trust boundary lives. Each participant should apply their own ingress policy on their IXP-facing interfaces. The IXP itself should probably document a recommendation that participants not trust DSCP from the peering LAN, and ensure their own route-server infrastructure and management plane have adequate CoPP regardless of what anyone marks. On RFC gaps You're right that RFC 4594 (6) is insufficient. The closest thing to operational best practice is probably RFC 2474/2475 themselves, since the DiffServ architecture explicitly describes trust boundaries and per-domain behavior, along with the operational guidance in RFC 4594 and RFC 8100. But none of them give you a copy-paste config, because the answer is inherently per-platform and per-policy. This might actually be a good candidate for a MANRS or BCOP document. The short version Don't rewrite. Don't blindly trust. Decouple the DSCP header from your local scheduling decision. Protect your strict-priority queues. This gives you neutrality because you preserve the customer's marking, security because your control plane is isolated, and fairness because no customer can game your scheduler. Hope this helps move the discussion forward. This really deserves to become a documented best practice. Have a good one, Paolo Caparrelli GOLINE SA -----Messaggio originale----- Da: Martin Passard <martin.passard@ielo.net <mailto:martin.passard@ielo.net>
Inviato: martedì 3 febbraio 2026 15:19 A: manrs-community@elists.manrs.org <mailto:manrs-community@elists.manrs.org> Cc: Tech IELO <tech@ielo.net <mailto:tech@ielo.net> > Oggetto: [manrs-community] Best practice over DSCP and priority as an ISP and IX and QOS in General Hello dear MANRS community, We, at IELO (AS29075), are working on the question of DSPC tags transparency as ISP. To give more context, we are a French neutral infrastructure network operator, Tier 2 over France and west-europe and our main focus regarding products like transit or our FTTO with DIA are to be as neutral and efficient using peering over western Europe, PNI and multiple tier1 transits. On our internal network, like a lot of others, we have classification over equipment using for exemple Cisco "Traffic class", seeing old IP Precedence matching to mark signaling protocols from the very old RFC 791 to ensure that for our core interface, signaling protocols are put inside the best queue of the 7 on them. We currently do not (in most of cases) move any of DSCP service fields on our network, however, we do know that on our equipment, by defaults, DSCP fields P.E. of clients traffic will be, by default on the equipements, be interpreted and moved automatically into queues, that we might want to avoid. For exemple any client pushing all DSCP traffic with high priority value would if not changed, be interpreted as important as internal protocols. We do have seen other network resetting DSCP fields to 0 and other QoS parameters of trafic they do transport. On our side, we hesitate on how to manage client trafic "abnormal" trafic. Let's not say it's not non-legitimate, but might be wrongly interpreted by default behavior of network equipment. We do mostly do think that a best practice for a network operator should be to change clients interfaces to restrict high priority queues while not resetting DSCP field. It's an easy way to ensure to this day that we would keep everyone equal, but changing it, is by our current point of view, is a non-neutral action. However, attacks using DSCP field to abuse queuing behavior and might disturb equipment since they don't care what trafic it is before moving the queues is a difficult questions. RFC 4594#section-6 tries to answer a bit of it but lacks content and real issue. So, after exposing that, what we do ask for your opinion on the subject is : Should ISP and IXP remove (for exemple, many variants exists here) DSCP CS6 and CS7 fields from client trafic to reserve them for real signaling protocols and internetworking ? Or should we adapt our equipment policy to explicitly change the queue of such traffic without modifying them, thus making keeping the information of it quite difficult. Or should do not change any of them to keep as transparent as we can even though we might have trafic abusing equipment mechanics appear over the time. Or maybe should we all implement it the other way around by never using high priority to be used unless we exactly know that the trafic is to be treated as is and so only make priorisation where we are perfectly sure of it. Or anything else? What do you all think and manage these fields on your backbone and how we should reacts over them ? What should be/is the best practice for being neutral to them without having abusive flows? I think this question is important as well over IXP, where I think it could be as well be something to watch, and where the answer to the best practice to apply might vary here. I know this question clearly is NOT an hot topic for anyone, and probably is, let's say... not in vogue at all for anyone. But while it went inside our minds as we saw it and talked about it in our own team we could not reach an informed consensus on what's best for both internet transparency while avoiding abuse nor find. Best regards -- Martin Passard AS29075.net ielo.net Peering Manager / Network engineer -- Messaggio analizzato da Libraesva ESG. Segnala come spam. <https://mail3.goline.ch/action/4f6M8w1slxzMK8m/report-as-bad> Mettilo in blocklist. <https://mail3.goline.ch/action/4f6M8w1slxzMK8m/blocklist>