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
On 3 Feb 2026, at 15:18, Martin Passard <martin.passard@ielo.net> wrote: [..] We do have seen other network resetting DSCP fields to 0 and other QoS parameters of trafic they do transport.
Cross-ISP / "Internet" QoS does not exist. Only if you would agree with another network what the meaning of the bits are, could it maybe make sense, but in general it does not, as the whole path has to agree and be provisioned for it. Hence, one should either ignore those markings, and all equipment that those packets passes should then ignore it) or zero them out, and possibly even outbound strip them. Ignoring is the easier way. With the last decade move to more privacy, QoS has started to make even less sense as it should not be known what is inside the packet. Though SSH actually is one of the tools that sets it: https://undeadly.org/cgi?action=article;sid=20250818113047 The situations for the need of QoS are primarily related to oversubscribed links, in that situation one has a bigger issue already: upgrade the links instead. One thing one should be looking at though is Buffer Bloat https://www.bufferbloat.net/projects/ Read the many pages on there, or the many presentations that Dave Täht (RIP!) have given over the last decades. Regards, Jeroen
My personal opinion that ISPs should /ideally/ not remark DSCP. However, I do not feel strongly about this. If an ISP flattens all the DSCP to 0, it probably doesn't matter in practice. If I understood correctly, one major international network recently told me they flatten everything to DSCP 0. I have implemented prioritization at layer 2. So we do /ignore/ DSCP when determining the incoming traffic class of traffic. All Internet traffic gets CoS 0 (e.g. by "qos cos 0"). In my gear, I believe CoS 0 is actually traffic-class 1 under the hood, such that CoS 1 can be traffic-class 0 for below best effort. We do not use below best effort, though. We have non-Internet traffic that gets prioritized. For example, SLAed point-to-point Ethernet circuits get a higher CoS value (again fixed, regardless of the customer's incoming p-bit or DSCP). Prioritization is maintained through the network using VLAN p-bit values. That means I do MPLS-in-VLAN, which feels a bit odd and requires extra configuration (i.e. a separate "interface Vlan123"). I would like to use MPLS EXP bits, but my vendor does not seem to support explicit null labels. Without the VLAN p-bit, penultimate hop popping would thus lose the priority value to the last /router/. Priority still matters at the last router because there are switches and PON access gear behind the router. So we /should/ be transparent to DSCP. I think we have been when I've looked, but I can't remember for certain. Again, take this all with a grain of salt. I'm just one guy at a little ISP. As always, if I'm doing something dumb, I welcome education from others. -- Richard
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> Inviato: martedì 3 febbraio 2026 15:19 A: manrs-community@elists.manrs.org Cc: Tech IELO <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
Hello everyone and thanks a lot for all of your responses! Paolo, I think you perfectly got the operational question I've tried to reach here. I think most operators does not do any actions with theses fields as only people making QoS ends up having trouble with them, but we all have equipment we must be sure on how they manages theses fields. We know that Cross-ISP / "Internet" QoS does not exist. That was not exactly my point to begin with. On the fact that :
The situations for the need of QoS are primarily related to oversubscribed links, in that situation one has a bigger issue already: upgrade the links instead
I want to respond with one exemple where it might matters: We do, for our customers ISPs in one of our products offer guaranteed bandwith with supplementary bandwidth for FTTO. But they of course theses ISP required us to provide a way to tag and in garanteed bucket some traffic to avoid having issues with, for exemple VoIP. This is a different offer than what we usually do: by rate-limiting strictly the trafic and letting the client ISP manage traffic-shaping to avoid drops. Just an exemple here. Not to be taken as more than that. And with our current equipment and bandwidth, we clearly don't "need" them on a carrier level when we are serious enough to manage capacity planning you are right. That's not where I wanted to orient the discussion at first but that's a correct thing to say on a network best-effort designed like internet as we should avoid congestion. You are making a point on how the internal queuing and the DSCP are often coupled with internal queues assignments. That's exactly what I did want to point out but you expressed it way better. Clearly, I don't think much operators checks that the queues are properly decoupled when it comes from untrusted interfaces, moreover I think this don't even comes to minds to most networks operators to check what happen regarding CS6/CS7 traffic. I think on my side that we should check all core routers we have exposed and know what they do. As said: "No transit packet, regardless of its DSCP value, should ever land in those queues". And YES exactly because the answer is inherently per-platform and per-policy I think it's worth to be considered. I would add moreover than per-platform we might special things to consider such as reserved memory spaces and different controlplane/dataplane architecture with them. And I of course agree that client traffic should always be kept in the default queue (except very rare cases). Now, it's easy to manage how it goes on inbound port, but after forwarding that's where it become more tricky. I think also that be sure to ignore it everywhere is the best in case of nothing can be done. But we must ensure that we DO that. In our case at IELO we don't have this case as most of our trafic is transparently L2 encapsulated into MPLS with EXP bit set as most of our trafic is wholesale last mile FTTO or L2L for providers delivered on NNI. On our old Cisco NCS equipment, we do have classifiers (class-map + set traffic-class X) ingress and outgress priority level based on signaling vs MPLS traffic. And for our transit/DIA clients for exemple, for beeing forwarded we add label to the "closest" BGP/DFZ router as they expose default to IGP. But I do think of networks that do not use MPLS for that kind of stuff. After being forwarded, if it wasn't rewritten, such network would still have to discriminate on "locally-originated" or not to avoid abuse of high-priority queues. There are ways to ensure that, and rewriting to 0 is a quick, working but dirty way in my personal opinion. But surely it "works". Thanks a lot for everything, all of your points of views here have been great for overall joint reflection on the subject. So, to sum up : This really deserves to become a subject for a best practice I think too. We should lab on our own core equipment what these (a bit) forgotten bits do. This might actually be a good candidate for a MANRS or BCOP document afterwards on how to decouple DSCP-to-queue mapping, I agree very much. Maybe there is nothing more to be explored here, and brand new equipment have enough of everything (queue size for exemple) to avoid anything too bad to happen. But I want to point out that like you say, these queues on our equipment should be kept under watch and it's basic infrastructure hygiene to avoid letting DiffServ be used outside of the small box it was design to stay in. By design on our side we avoid it with MPLS with our own EXP bits sets. But indeed, where there is risk is client facing interface and all transit/IXP interfaces we have. Best regards and thanks for your contributions Le 05/02/2026 à 00:22, Caparrelli Paolo a écrit :
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 c,onnected 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> Inviato: martedì 3 febbraio 2026 15:19 A: manrs-community@elists.manrs.org Cc: Tech IELO <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
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> Date: Thursday, February 5, 2026 at 09:37 To: Martin Passard <martin.passard@ielo.net>, manrs-community@elists.manrs.org <manrs-community@elists.manrs.org> Cc: Tech IELO <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> Inviato: martedì 3 febbraio 2026 15:19 A: manrs-community@elists.manrs.org Cc: Tech IELO <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
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>
participants (5)
-
Caparrelli Paolo -
Jeroen Massar -
Livingood, Jason -
Martin Passard -
Richard Laager