QoS for Office365

Mon Jul 8 22:35:58 UTC 2019

On Mon, Jul 8, 2019 at 5:50 PM Mark Tinka <mark.tinka at seacom.mu> wrote:
>
>
>
> On 8/Jul/19 21:03, Robert Webb wrote:
> > I took the OP's request as for doing QoS at the edge of their network
> > and not necessarily the entire path.
>
> Indeed, but even then, you could be handing off the traffic to a
> downstream customer, and can't guarantee what they do to those ToS fields.

I disagree -- you *can* guarantee what someone else will do with your
ToS fields....... they will A: ignore them and / or B: scribble all
over them.

At a previous employer (AOL, doing VoIP for customer service / call
centers, ~2004) we had a number of contractual agreements with
multiple providers to honor our QoS markings -- as far as I could tell
(marking test traffic under congestion events) only one of about seven
did anything at all with the marking, and that wasn't enough to make
any difference... I briefly toyed with the idea of asking for some
money back / trying to enforce the terms of the agreements, but
figured that there wasn't much point - expecting QoS to work in
someone else's network based upon your markings seems like a fool's
errand.

W

>
>
> >
> > As another person stated, the real answer is to add more bandwidth if
> > you are having to QoS to Office365 because it is affecting other
> > internet based services.
>
> Yes and no.
>
> More bandwidth never hurt anyone, but packet loss in the remote network
> toward the cloud will hurt you.
>
> Mark.

-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf