QoS for Office365

Tue Jul 9 15:50:19 UTC 2019

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20190709/bc866df1/attachment.html>