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

[matt at theaddisons.us]

job at bsd.nl <http://bsd.nl/> wrote:
> It is important to note that _only_ interactive traffic (i.e., real-time
> traffic resulting from people typing into their terminal) is marked EF.
> Any other SSH traffic (e.g., sftp/scp traffic, X11 forwarding, etc) is
> marked with the operating system default, usually CS0.

And the *responses* coming from the interactive application right? If there are only interactive sessions on the ssh connection, `cat /dev/urandom` (or tailing a highly active log file, or cat’ing any large file) is going to send traffic into the EF queue as fast the machine can put it on the wire (and get ACKs) - and those are full size datagrams, not 20ms paced 200 byte RTP datagrams which is the expectation for EF. Or is there internal rate limiting to prevent the application from exhausting the EF queue and causing a problem for everyone else on the network? Or causing the ssh session to needlessly retransmit traffic if the QoS application at the route/switch layer is good and prevents a single endpoint from consuming it all; all which would have been avoided by simply not using the EF codepoint without scavenger fallback, and instead using a CSx codepoint which generally has scavenger fallback. (RFC3246 sec 3, RFC4594 sec 1.5.3)

> > This has been observed recently on this list with Oliver Freyermuth’s
> > posts starting from October of 2025. His provider eventually resolved
> > this
> 
> Yes! Emphasis mine: "HIS PROVIDER EVENTUALLY RESOLVED THIS". I interpret
> this anecdote as a success story: it could very well be that OpenSSH's
> implementation choices nudged this particular provider to improve their
> service offering, who knows. In any case, active use of codepoints is an
> important way to ensure such codepoints remain usable over time.

The provider bleaching at ingress to work around bad application behavior seems to me to be the *opposite* of ensuring the codepoint remains usable over time (not that it ever really had much usability over the DFZ, absent selected providers allowing it for access to their hosted services, and Barik’s research showing it has a minor positive effect on latency across 3% of links, and a detrimental effect across 2%- but this research didn’t look at the variety of access networks like Freyermuth’s where it was 100% detrimental and unexpectedly caused all traffic to drop). And is encouraging more non-RFC compliant (and thus, unexpected and undocumented) behavior. Also worth noting, this is only one report from a highly technical user on this list, countless other less-technical users have been impacted by this and had to solve it by dropping the application back to sane defaults (no DSCP marking) even before the change to use EF. Again, consult the Google search for 'sshd "ipqos 0x00" OR "ipqos cs0”’ for all the users who didn’t find their way to the upstream where this problem originated. 

> The joy and quality of interactive work is latency sensitive, most users
> will feel comfortable typing at a latency between 20-150ms. As DSCP
> value EF ultimately maps to the WMM AC_V0 access category (following the
> reconciled IETF Diffserv to IEEE 802.11 mappings, RFC 8325), on modern
> operating systems with modern WiFi, your SSH keypresses essentially are
> given a tiny boost to reach the access point. How cool is that!

Which is contrary to RFC8325 recommendations in 4.1.2 for OAM traffic (which includes SSH). If you were going to use another section of RFC8325 for the SSH application, 4.2.4 seems more appropriate, which recommends CS4 to map to AC_VI, which will effectively prioritize over the best effort traffic in the WLAN environment, without causing problems in the wired one. 

This is valuable behavior in the right environment- I just question if it is the right *default* for such a widely used piece of software given the demonstrated potential to violate the principle of least astonishment.