I respectfully just don't agree on that. In my view, software should default to not setting those bits to anything by default, but should have configuration options that allow them to be set if required. Every network is different, and making assumptions based on RFC SHOULD's is an unfortunate choice.

On Tue, Jul 9, 2019 at 11:22 AM Saku Ytti <saku@ytti.fi> wrote:

Hey Tom

> That's already been happening. OpenSSH pulled that stunt in 7.8.

OpenSSH always coloured interactive and non-interactive SSH. They just
used original TOS definition, which no one has used in the field, not
in the last 20 years at any rate. And which devices actually cannot
even match for (They can match PREC, DSCP definition of TOS, not
original). But it took some time of convincing OpenSSH people that
reading original RFC isn't going to give sufficient understanding of
how TOS is used in real network.

I applaud this change. In home use your WIFI actually does honour QoS
and many enterprise networks do. And they mostly will align with this
default. So it's good default.

Home user internet experience would be vastly superior if WAN would
also do some rudimentary QoS, one silver bullet is to prioritise small
packets during congestion. Makes so much better experience on people
who regularly have their WAN uplink congested. Sadly not widely done
and impossible in most cases to do for NET=>Customer direction. Would
be terrific if CPE could tell far-end what QoS policy to use, so
residential users could decide on their end the far end QoS config.

--
++ytti