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

On Sat, Apr 11, 2026 at 10:51:51AM +0200, Hendrik Visage wrote:
> Well... since Trixie/Excalibur (Debian 13 / Devuan 6) I've seen some
> SSH network "hangs" which might just be explained by these bits and
> the networks I cross.

No, you have now in fact added a point to the contrary: these "hangs"
you report are entirely unrelated to any of the changes under
discussion, because Debian Trixie shipped with a debian-specific set of
patches applied to version of 10.0.

> The "fun" with especially RedHat and Debian, is they don't do that
> much "incremental" and are quite bang releases, thus, a claim like
> this doesn't quite hold water as we see it not when it get's released,
> but when the version after this baked in in release get released by
> the distros.

This is not a fact. To mitigate exactly what you describe, the Debian
project works hard to offer "Sid", which is a rolling release applying
only incremental change. Debian Sid is frequently synced to the latest
OpenSSH upstream. In addition to Sid, there also is a preview of the
next release in the form of https://www.debian.org/releases/testing/ to
provide even more help to system administrators to prepare for change.

I think what you are saying is that you do not participate in testing
the system software you rely on. And consequently, because you fail to
test the software provided to you for testing purposes, yes, any kind of
release is going to come as a shock.

> For the better part I'd advocate that you have this as opt-in not
> opt-out (or baked in) behaviour, as then the network/etc. operator can
> decide themselves when/if a specific router/switch does need the EF
> bit or not. 

You can already decide this for yourself, see "man ssh_config". Nobody
is taking that away from you.

> 'cause several times those same network operators would be pushing
> configs emass (or other information gathering scripts using keyboard
> interactive expect sessions) that would want to have it turned it off
> during those sessions as a default (not the opposite)

Yes, it is well understood there are rare circumstances where the
default configuration might not fit a particular environment. For this
exact reason, users are given much leeway in the form of documentation
and configuration options which they may change as they deem necessary.

> I do hope that Theo & Damien would reconsider this and make it opt-IN
> settings for those that feel/have the need/use to enable it as they
> require it, and not a blanket aggresive setting

Again, applications should be able to mark packets so that the local
network can work optimally. And, of course, the local network extends
into other networks, such as the Internet. At the various borders
between the networks the responsible administrators will either reset
or tunnel traffic class markings, either of those two ways is fine, but
dropping traffic is insane. Anyone adhering to a different philosophy
cannot mark any traffic ever, not even in their local network, and
that's just not how it is.

- Job