Current behavior to set DSCP EF code point by default is harmful

[matt at theaddisons.us]

> On Apr 9, 2026, at 10:07 PM, Theo de Raadt <deraadt at openbsd.org> wrote:
> 
> Damien Miller <djm at mindrot.org> wrote:
> 
>> Just to make my position clear - unless there's a very strong reason not to,
>> I'm going to follow what Job decides here. He is much closer to the network
>> operator community than anyone else who directly works on OpenSSH and so I
>> defer to his knowledge and judgement here.
> 
> I'm mostly in the same position.

Which is a fair default position for both of you to take, I don’t typically engage in open source software development (although my fixes have made it into a few), and I’m not as active with social network operator groups as Job is, but I am approaching this as a network operator who has managed QoS for a regional DIA/MPLS/SIP/colocation/managed services provider (yes, the owner basically wanted us to be a one stop shop for everything short of the desktop). When all a customer has is a T1 (and yes, there are still a minority of offices out in the world today connected via T1/E1, either for DIA or MPLS access), and they want to use VoIP, QoS is critical. 

Job’s main consideration of this so far appears to be in a single-hop environment, since the argument hinges on RFC8325. If the destination where within the same broadcast domain as the source I couldn’t care less what DSCP marking you use, but I don’t think selectively applying DSCP based on source/destination IP is a complexity you’d want to bring into openssh. 

> First, I think the complaint is trying to specify the rules for DSCP stronger
> than what the standard really says.

The RFCs around DiffServ aren’t normative, because they’re not dictating a protocol specification where things have to play nice, there’s no MUST or MUST NOT in these standards, they’re full of SHOULD, because they’re full of the wisdom of a room of network operators, vendors, and academics who’ve discussed the topic at IETF meetings. They make those recommendations for a reason, ignore them at your own (and all your users) peril. 

> Secondnly, there is also the matter how DSCP is actually deployed in
> practice.  The negative scenario described seems rare and contrived,
> sorry but I feel there's an unrealistic agenda attached which we can't
> see.

The agenda is protecting networks which aren’t as well deployed as Job’s, which is the vast majority of them. Because the majority of networks out there don’t have the luxury of a dedicated OOB/DCN like you’d see deployed by the settlement free club that Job’s $DAYJOB is a member of where EF can be used without impacting other services. I mostly came here out of concern for other networks (not so much my own production network, since we don’t guarantee QoS in our IP backbone after we divested our SIP services) in response to someone asking the opinions of other more enterprise focused network administrators on reddit, and the suggestion that *someone* should bring this to the attention of this list: https://www.reddit.com/r/networking/comments/1sb9yua/opinions_on_qos_in_openssh/

Some of the people there were a little more passionate than I was in their opposition. And no, I'm not the poster suggesting physical violence against the people that thought this was wise (not that I think they were that that serious about it). 

> We deployed this in OpenSSH incrementally and substantially for 6
> months, and by my recollection have heard only two concerns previously
> which both turned out to be incorrect ISP segment configurations, which
> were corrected after the customer reached out.  One of them was only on
> certain segments of the ISP, the other I don't believe we got details
> on.  One configuration was so incorrect the other trafffic was also
> being blackholed.  Screaming at ISPs who deploy it incorrectly is more
> valuable effort, not at tiny stack software which often uses it for
> critical traffic.

Those are the ones you *heard* about, from highly technical users, who thought to come to the openssh-unix-dev mailing list. Again, see Google for all the others that didn’t make it to you. And you’ll never hear from the ones who solved the problem the defaults created over the years on their own because they found one of the hundreds of discussions on the internet (like the Debian Wiki, or stack overflow thread, or Raspberry Pi groups because apparently this apparently broke on some RPi compatible hardware) where they’re advised to just set "IPQoS 0x00” or “IPQoS throughput”. 

> I think we can afford to wait for the community to understand that the
> majority of SSH traffic is minimal, generally either trivial volume or
> for critical management, is as valuable as voice, if not more.  To me,
> that's a better future.  EF isn't just cat videos, otoh I suspect it
> contains almost no 911/112 calls.

Which is why the RFC9345 authors, in collaboration with the Transport and Services Working Group at the IETF recommended SSH be placed into the OAM category. So it would receive preferential treatment over bulk traffic in well configured networks. The folks who wrote RFC8325 (in the same working group, but the RFC was only considering the wireless domain) didn’t make this same consideration, and OAM mapped into AC_BE in their recommendations. They have an either/or for network control traffic (which I would hope Job and I would both agree is more important than SSH) to place it into AC_V0 or AC_BE- but that uses CS6 and not EF. 

Marking SSH traffic with EF is saying it’s more important than (and should be serviced by the router before) BFD, BGP, and OSPF, all of which are absolutely critical services- if we drop enough of those packets *all* traffic drops- thankfully that’s not likely to happen in most wired network. 
And EF should contain absolutely zero cat videos- that’s video/multimedia not telephony. It should however contain 100% of 911/112 calls made from softphones and desktop VoIP phones, because 911/112 calls *are* telephony. At least the voice content of that call, the signaling to set it up is typically in CS5. 

I think this is a good feature, but EF shouldn’t be the default. IMO one of CS2/CS4/CS6 should be the default, two of which would give elevated 802.11 priority (thus providing the slightly faster keystroke experience), without potentially congesting the EF queue in the wired portion of the network. Leaving this as a default is going to force more operators to either bleach traffic (which is what’s likely happened in every case where a user complains, because as an operator it’s *far* easier to just wipe all your DSCP markings if you’re not paying me to do anything with them), or implement changes which end up in SSH traffic being dropped (which is what’s likely happening before people complain and they bleach, because they’re applying strict priority to the traffic going into EF, so if your destination isn’t in their VoIP termination networks and you’re marked with EF you get dropped because you’re misusing their network). 

EF is using a hammer, when you should be using a screwdriver. 

> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev