<div dir="ltr">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. <div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jul 9, 2019 at 11:22 AM Saku Ytti <<a href="mailto:saku@ytti.fi">saku@ytti.fi</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey Tom<br>
<br>
> That's already been happening. OpenSSH pulled that stunt in 7.8.<br>
<br>
OpenSSH always coloured interactive and non-interactive SSH. They just<br>
used original TOS definition, which no one has used in the field, not<br>
in the last 20 years at any rate. And which devices actually cannot<br>
even match for (They can match PREC, DSCP definition of TOS, not<br>
original). But it took some time of convincing OpenSSH people that<br>
reading original RFC isn't going to give sufficient understanding of<br>
how TOS is used in real network.<br>
<br>
I applaud this change. In home use your WIFI actually does honour QoS<br>
and many enterprise networks do. And they mostly will align with this<br>
default. So it's good default.<br>
<br>
Home user internet experience would be vastly superior if WAN would<br>
also do some rudimentary QoS, one silver bullet is to prioritise small<br>
packets during congestion. Makes so much better experience on people<br>
who regularly have their WAN uplink congested. Sadly not widely done<br>
and impossible in most cases to do for NET=>Customer direction. Would<br>
be terrific if CPE could tell far-end what QoS policy to use, so<br>
residential users could decide on their end the far end QoS config.<br>
<br>
-- <br>
  ++ytti<br>
</blockquote></div>