Re: QoS for Office365

[Alan Buxey]

hi,

use Direct Access PAC file for clients to get the right endpoints.
Apply QoS to that traffic - and use that same PAC file to feed the IP
ranges into your QoS
rules on the firewall/router ?

alan

On Mon, 8 Jul 2019 at 17:15, Joe Yabuki  wrote:
>
> Hi all,
>
> How do you deal with QoS for Office365, since the IPs are subject to changes ?
>
> How can we mark the trafic while keeping the security (I fear the marking 
> based on TCP/UDP Ports since they are not without an additional risk coming 
> from worms/virus using those ports for example, and doing that directly on 
> the PCs doesn't seem to be the best solution) ?
>
> Many thanks,
> Joe

Re: QoS for Office365

[Mark Milhollan]

On Tue, 9 Jul 2019, Mike O'Connor wrote:


:How do you deal with QoS for Office365, since the IPs are subject to changes ?

How often is the data in:

https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges
https://docs.microsoft.com/en-us/office365/enterprise/office-365-ip-web-service

out of date?


They provide a REST interface ... "Endpoints data is updated at the 
beginning of each month with new IP Addresses and URLs published 30 days 
in advance of being active."  Last updated 6/28.  There's also 
 for 
this specific case.



/mark

Re: QoS for Office365

[Mark Andrews]

That’s why you do QoS between the customer’s packets not every packet.

> On 10 Jul 2019, at 12:46 am, Steve Mikulasik via NANOG  
> wrote:
> 
> Even if QoS on the Internet was possible it would be destroyed by everyone 
> marking all their traffic with the highest priority to get the best 
> performance. Tragedy of the commons. 
> 
> 
> 
> -Original Message-
> From: NANOG  On Behalf Of Mark Tinka
> Sent: Monday, July 8, 2019 10:40 AM
> To: nanog@nanog.org
> Subject: Re: QoS for Office365
> 
> 
> 
> On 2/Jul/19 23:18, Joe Yabuki wrote:
> 
>> Hi all,
>> 
>> How do you deal with QoS for Office365, since the IPs are subject to 
>> changes ?
>> 
>> How can we mark the trafic while keeping the security (I fear the 
>> marking based on TCP/UDP Ports since they are not without an 
>> additional risk coming from worms/virus using those ports for example, 
>> and doing that directly on the PCs doesn't seem to be the best solution) ?
> 
> Funny, I was just answering an internal question about this, last week.
> 
> As with all things Internet, my stance is if you don't have end-to-end 
> control, trying to do QoS is pointless.
> 
> That said, I believe it should be possible to apply some kind of meaningful, 
> end-to-end QoS together with Microsoft if you took up one of their Express 
> Route services, given that is considered a private, premium service.
> 
> Mark.
> 

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742  INTERNET: ma...@isc.org

Re: QoS for Office365

[Mike O'Connor]

:How do you deal with QoS for Office365, since the IPs are subject to changes ?

How often is the data in:

https://docs.microsoft.com/en-us/office365/enterprise/urls-and-ip-address-ranges
https://docs.microsoft.com/en-us/office365/enterprise/office-365-ip-web-service

out of date?  


-Mike

-- 
 Michael J. O'Connor  m...@dojo.mi.org
 =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--=
"Nothing unreal exists." -Kiri-Kin-Tha's First Law Of Metaphysics


signature.asc
Description: PGP signature

Re: QoS for Office365

[Brian Knight]

> On Jul 9, 2019, at 9:19 AM, Mark Tinka  wrote:
> 
> 
> 
>> On 9/Jul/19 16:18, Ross Tajvar wrote:
>> I think the difficulty lies in appropriately marking the traffic. Like
>> Joe said, the IPs are always changing.
> 
> Does anyone know if they are reasonably static in an Express Route scenario?
> 
> Mark.

Yes, the IPs used on the ExpressRoute connection are whatever is chosen for the 
internal IP scheme of the VPC. ExpressRoute is a VPN connection into that 
internal side of a VPC.  On our carrier (MegaPort), ExpressRoute looks similar 
to an Option A NNI connection. BGP is used for routing.

The source IPs on packets crossing out of the VPC onto the Azure-provided 
Internet may or may not be static, but internally they are usually static RFC 
1918 addresses.

We’ve been using ExpressRoute for our own office systems and a small handful of 
customers for about two years now. However, we don’t use diffserv on 
ExpressRoute, so can’t comment on that.

-Brian

Re: QoS for Office365

[Warren Kumari]

On Tue, Jul 9, 2019 at 10:02 AM Tom Beecher  wrote:
>>
>> 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.
>
>
> Generally speaking, I agree that making QoS features work consistently on an 
> external network you do not control is a fool's errand.
>
> But if that language was inserted into the contracts, and you can 
> demonstrably prove it's not being done, enforcing contract terms should 
> always be done. Depending on the strength of the remedy, could have been a 
> lot of free service, enough financial incentive for them to MAKE it work 
> correctly, or leverage to open renegotiations for more favorable terms for 
> you.
>
> You know that in reverse they would have done the same to you. :)
>

Yeah, at that point in AOL's trajectory there were (at least from my
point of view!) much much bigger issues -- like, "Who's getting laid
off this week? and how do I remove their access? and who's going to do
whatever they were doing (if anything)?!" and trying to make enhanced
cRTP work over GRE over yet more GRE over IPSEC (because, well,
reasons).
Yes, in an ideal world we would have received some sort of credits --
but then again, in an ideal world, I wouldn't have been trying to run
VOIP over cRTP over GRE over GRE over IPSEC over DS3 to E3 converters
to India...

W


> On Mon, Jul 8, 2019 at 6:38 PM Warren Kumari  wrote:
>>
>> On Mon, Jul 8, 2019 at 5:50 PM Mark Tinka  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



-- 
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

Re: QoS for Office365

[Edward Salonia]

Have you looked into Cisco’s SD-AVC? Also with the o365 connector?

https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/avc/sd-avc/2-1-0/ug/sd-avc-2-1-0-ug.pdf


On Jul 2, 2019, at 17:18, Joe Yabuki  wrote:

Hi all, 

How do you deal with QoS for Office365, since the IPs are subject to changes ?

How can we mark the trafic while keeping the security (I fear the marking based 
on TCP/UDP Ports since they are not without an additional risk coming from 
worms/virus using those ports for example, and doing that directly on the PCs 
doesn't seem to be the best solution) ?

Many thanks,
Joe

Re: QoS for Office365

[Tom Beecher]

I looked back into work email from back then and I see where I made my
mistake. I had misread the 7.4 change where they added the option for allow
IPQoS=none , apparently my brain just skipped the word 'option', and it
stuck in my brain as the default behavior being 'none'. That's
embarrassing, thank you for correcting me.

On Tue, Jul 9, 2019 at 12:19 PM Saku Ytti  wrote:

> On Tue, 9 Jul 2019 at 18:50, Tom Beecher  wrote:
>
> > 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.
>
> You are entitled to that opinion, I just wanted to correct you that
> this is not a change in OpenSSH behaviour from your point of view,
> just different bits. For you it's business as usual.
>
> I don't anticipate Internet users in general to be capable of
> configuring QoS and I think they deserve reasonable defaults, and
> those who understand what they want, can change those defaults. The
> WLAN AP you shop from typical provider has QoS built-in, and it works
> reasonably, with reasonable definition.
> I wish we'd take it further, and give reasonable last mile QoS to
> consumer, the 'small packets first in congestion' would on average
> increase user experience significantly.
>
> --
>   ++ytti
>

Re: QoS for Office365

[Mark Tinka]

On 9/Jul/19 17:06, Joel Jaeggli wrote:
> Express route peering  with 12076 gives you more specific routes then you 
> would otherwise see from 8075 (a /13 becomes a bunch of 17s etc) . it also 
> gives you control over what region / application is exported to you.

As I had assumed.

But of course, you'd pay for that private service :-).

Mark.

Re: QoS for Office365

[Saku Ytti]

On Tue, 9 Jul 2019 at 18:50, Tom Beecher  wrote:

> 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.

You are entitled to that opinion, I just wanted to correct you that
this is not a change in OpenSSH behaviour from your point of view,
just different bits. For you it's business as usual.

I don't anticipate Internet users in general to be capable of
configuring QoS and I think they deserve reasonable defaults, and
those who understand what they want, can change those defaults. The
WLAN AP you shop from typical provider has QoS built-in, and it works
reasonably, with reasonable definition.
I wish we'd take it further, and give reasonable last mile QoS to
consumer, the 'small packets first in congestion' would on average
increase user experience significantly.

-- 
  ++ytti

Re: QoS for Office365

[Paul Thornton]

On 09/07/2019 16:27, Jay Ford wrote:

On Tue, 9 Jul 2019, Mark Tinka wrote:

On 9/Jul/19 16:18, Ross Tajvar wrote:

I think the difficulty lies in appropriately marking the traffic. Like
Joe said, the IPs are always changing.


Does anyone know if they are reasonably static in an Express Route
scenario?


At least sometimes M$ says that Express Route is just for Azure, not for
Orifice 365.  It's even possible that using Express Route for O365 could
be worse due to undermining/bypassing some of the O365 availability
mechanisms.


I've just been involved in turning up a new customer who ordered Express 
Route specifically for O365 use - they have no Azure presence.


After much discussions between us, the customer and MS it transpired 
that they (MS) really didn't want to support using Express Routes and 
O365 - there had been many instances of routing problems and people not 
really understanding what the end result was going to look like. 
Apologies for being vague here, but I wasn't directly in the loop - 
except to say that MS dissuaded the customer from this and told them to 
just use their Internet connection instead.


The MS techs told us that this was their preferred option now.  A year 
or two back, they wanted everyone to access O365 via Express Route...


Paul.

Re: QoS for Office365

[Tom Beecher]

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  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
>

Re: QoS for Office365

[Jay Ford]

On Tue, 9 Jul 2019, Mark Tinka wrote:

On 9/Jul/19 16:18, Ross Tajvar wrote:

I think the difficulty lies in appropriately marking the traffic. Like
Joe said, the IPs are always changing.


Does anyone know if they are reasonably static in an Express Route scenario?


At least sometimes M$ says that Express Route is just for Azure, not for 
Orifice 365.  It's even possible that using Express Route for O365 could be 
worse due to undermining/bypassing some of the O365 availability mechanisms.


__
Jay Ford , Network Engineering, University of Iowa

Re: QoS for Office365

[Saku Ytti]

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

Re: QoS for Office365

[Tom Beecher]

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

https://www.openssh.com/txt/release-7.8

 ssh(1)/sshd(8): the default IPQoS used by ssh/sshd has changed.
   They will now use DSCP AF21 for interactive traffic and CS1 for
   bulk.  For a detailed rationale, please see the commit message:
   https://cvsweb.openbsd.org/src/usr.bin/ssh/readconf.c#rev1.284




On Tue, Jul 9, 2019 at 10:50 AM Steve Mikulasik via NANOG 
wrote:

> Even if QoS on the Internet was possible it would be destroyed by everyone
> marking all their traffic with the highest priority to get the best
> performance. Tragedy of the commons.
>
>
>
> -Original Message-
> From: NANOG  On Behalf Of Mark Tinka
> Sent: Monday, July 8, 2019 10:40 AM
> To: nanog@nanog.org
> Subject: Re: QoS for Office365
>
>
>
> On 2/Jul/19 23:18, Joe Yabuki wrote:
>
> > Hi all,
> >
> > How do you deal with QoS for Office365, since the IPs are subject to
> > changes ?
> >
> > How can we mark the trafic while keeping the security (I fear the
> > marking based on TCP/UDP Ports since they are not without an
> > additional risk coming from worms/virus using those ports for example,
> > and doing that directly on the PCs doesn't seem to be the best solution)
> ?
>
> Funny, I was just answering an internal question about this, last week.
>
> As with all things Internet, my stance is if you don't have end-to-end
> control, trying to do QoS is pointless.
>
> That said, I believe it should be possible to apply some kind of
> meaningful, end-to-end QoS together with Microsoft if you took up one of
> their Express Route services, given that is considered a private, premium
> service.
>
> Mark.
>
>

Re: QoS for Office365

[Saku Ytti]

On Tue, 9 Jul 2019 at 17:37, Valdis Klētnieks  wrote:

> But how did you verify they "worked" as far as actually dropping packets off
> the correct flow (especially since if you have a high-priority QoS, the flow 
> that
> loses may be some other customer's flow)?

By congesting queues and verifying expectations to results.

-- 
  ++ytti

Re: QoS for Office365

[Joel Jaeggli]

> On Jul 9, 2019, at 07:19, Mark Tinka  wrote:
> 
> 
> 
> On 9/Jul/19 16:18, Ross Tajvar wrote:
>> I think the difficulty lies in appropriately marking the traffic. Like
>> Joe said, the IPs are always changing.
> 
> Does anyone know if they are reasonably static in an Express Route scenario?

Express route peering  with 12076 gives you more specific routes then you would 
otherwise see from 8075 (a /13 becomes a bunch of 17s etc) . it also gives you 
control over what region / application is exported to you.

My early experience as a customer with it was that there was on RPF check that 
I found to be a problem as a multihomed network.

> 
> Mark.
> 

Re: QoS for Office365

[Mark Tinka]

On 9/Jul/19 16:46, Steve Mikulasik wrote:
> Even if QoS on the Internet was possible it would be destroyed by everyone 
> marking all their traffic with the highest priority to get the best 
> performance. Tragedy of the commons. 

I kind of like the Internet the way it is. The best-effort nature is
what allows us to build it in a way that makes it a viable option for
global data transport.

If all paths on the Internet had to be high-priority, I doubt it'd be a
viable project outside of a monopoly or duopoly.

Mark.

Re: QoS for Office365

[Mark Tinka]

On 9/Jul/19 16:37, Valdis Kl ē tnieks wrote:

> I'll bite.
>
> It's one thing to verify that no routers molested the QoS bits along the
> packet path.
>
> But how did you verify they "worked" as far as actually dropping packets off
> the correct flow (especially since if you have a high-priority QoS, the flow 
> that
> loses may be some other customer's flow)?

With some things, you need to have faith until you are given a reason
not to.

Just like when you are back in 26K and the Captain and his First Officer
are up front :-).

Mark.



signature.asc
Description: OpenPGP digital signature

RE: QoS for Office365

[Steve Mikulasik via NANOG]

Even if QoS on the Internet was possible it would be destroyed by everyone 
marking all their traffic with the highest priority to get the best 
performance. Tragedy of the commons. 



-Original Message-
From: NANOG  On Behalf Of Mark Tinka
Sent: Monday, July 8, 2019 10:40 AM
To: nanog@nanog.org
Subject: Re: QoS for Office365



On 2/Jul/19 23:18, Joe Yabuki wrote:

> Hi all,
>
> How do you deal with QoS for Office365, since the IPs are subject to 
> changes ?
>
> How can we mark the trafic while keeping the security (I fear the 
> marking based on TCP/UDP Ports since they are not without an 
> additional risk coming from worms/virus using those ports for example, 
> and doing that directly on the PCs doesn't seem to be the best solution) ?

Funny, I was just answering an internal question about this, last week.

As with all things Internet, my stance is if you don't have end-to-end control, 
trying to do QoS is pointless.

That said, I believe it should be possible to apply some kind of meaningful, 
end-to-end QoS together with Microsoft if you took up one of their Express 
Route services, given that is considered a private, premium service.

Mark.

Re: QoS for Office365

[Joe Yabuki]

Hi all,

Thanks for your replies,

I'll rephrase just to clarify, our aim is to do QoS within our extended LAN
(From remote sites to the Datacenter using the MPLS provider as transit) -
and we can't use DIA for a security reasons...

So arguably, we still need to mark/queue/police packets at the Edge of the
Internet and on the remote site. For INTERNET we will throw bandwidth so it
will not be a point of congestion (hopefully once we are in the Backbone's
ISP we will go to Microsoft directly)

Joe

On Tue, Jul 9, 2019 at 4:06 PM Mark Tinka  wrote:

>
>
> On 9/Jul/19 16:01, Tom Beecher wrote:
>
> >
> >
> > But if that language was inserted into the contracts, and you can
> > demonstrably prove it's not being done, enforcing contract terms
> > should always be done. Depending on the strength of the remedy, could
> > have been a lot of free service, enough financial incentive for them
> > to MAKE it work correctly, or leverage to open renegotiations for more
> > favorable terms for you.
>
> Perhaps plenty of service credits. Anything else would just burn too
> much time on either end for no practical outcome.
>
> Mark.
>

Re: QoS for Office365

[Valdis Klētnieks]

On Tue, 09 Jul 2019 17:16:52 +0300, Saku Ytti said:

> In previous life working with L3 MPLS VPN with deliveries far
> exceeding on-net size we bought access from partners and had QoS
> contracts in place, which were tested and enforced and they worked
> after some ironing during field trials.

I'll bite.

It's one thing to verify that no routers molested the QoS bits along the
packet path.

But how did you verify they "worked" as far as actually dropping packets off
the correct flow (especially since if you have a high-priority QoS, the flow 
that
loses may be some other customer's flow)?


pgpSXld_60SMw.pgp
Description: PGP signature

Re: QoS for Office365

[Mark Tinka]

On 9/Jul/19 16:23, Brandon Martin wrote:

>  
> To be fair, there are some folks who operate national or global big-I
> Internet IP networks that do guarantee QoS as long as you stay on
> their network.

Yes, which is the point... as long as the traffic is on-net, you can
guarantee things.

Large, global, transit-free backbones fair well in such scenarios as the
majority of the traffic lives on-net as a matter of course.

Mark.

Re: QoS for Office365

[Mark Tinka]

On 9/Jul/19 16:16, Saku Ytti wrote:

> In previous life working with L3 MPLS VPN with deliveries far
> exceeding on-net size we bought access from partners and had QoS
> contracts in place, which were tested and enforced and they worked
> after some ironing during field trials.
> Usually contract was bidirectional, with partner also using our
> network for extending reach of their network, so both had incentive to
> offer working QoS with network-edge translation of marking.

I think when the partner participates in a private service, end-to-end,
there's a higher chance things will work (which I believe is one of the
components for Inter-AS l3vpn's and QoS).

However, when part of the partner's offering is off-net (especially
where off-net = public Internet), much less likely.

Mark.

Re: QoS for Office365

[Brandon Martin]

On 7/8/19 4:01 PM, adamv0...@netconsultings.com wrote:

And yet the SD-WAN promising MPLS experience over the internet and other BS 
sells like crazy;)


To be fair, there are some folks who operate national or global big-I 
Internet IP networks that do guarantee QoS as long as you stay on their 
network.  Most of them operate an MPLS, too, no surprise.  Sprintlink is 
one that I know of.


They tend to be on the expensive side when it comes to IP service.
--
Brandon Martin

Re: QoS for Office365

[Mark Tinka]

On 9/Jul/19 16:18, Ross Tajvar wrote:
> I think the difficulty lies in appropriately marking the traffic. Like
> Joe said, the IPs are always changing.

Does anyone know if they are reasonably static in an Express Route scenario?

Mark.

Re: QoS for Office365

[Ross Tajvar]

I think the difficulty lies in appropriately marking the traffic. Like Joe
said, the IPs are always changing.

On Tue, Jul 9, 2019, 9:15 AM Mark Tinka  wrote:

>
>
> On 9/Jul/19 16:08, Joe Yabuki wrote:
> > Hi all,
> >
> > Thanks for your replies,
> >
> > I'll rephrase just to clarify, our aim is to do QoS within our
> > extended LAN (From remote sites to the Datacenter using the MPLS
> > provider as transit) - and we can't use DIA for a security reasons...
> >
> > So arguably, we still need to mark/queue/police packets at the Edge of
> > the Internet and on the remote site. For INTERNET we will throw
> > bandwidth so it will not be a point of congestion (hopefully once we
> > are in the Backbone's ISP we will go to Microsoft directly)
>
> In that case, co-ordinate the QoS profile with your MPLS provider and
> test both ends to make sure you receive what you send for on-net traffic.
>
> Verifying that your MPLS provider is forwarding your traffic according
> to the agreed-upon QoS profile is another thing.
>
> As for the off-net traffic entering your network, well, you know about
> that already...
>
> Mark.
>

Re: QoS for Office365

[Saku Ytti]

On Tue, 9 Jul 2019 at 17:05, Tom Beecher  wrote:

> Generally speaking, I agree that making QoS features work consistently on an 
> external network you do not control is a fool's errand.
>
> But if that language was inserted into the contracts, and you can 
> demonstrably prove it's not being done, enforcing contract terms should 
> always be done. Depending on the strength of the remedy, could have been a 
> lot of free service, enough financial incentive for them to MAKE it work 
> correctly, or leverage to open renegotiations for more favorable terms for 
> you.
>
> You know that in reverse they would have done the same to you. :)

In previous life working with L3 MPLS VPN with deliveries far
exceeding on-net size we bought access from partners and had QoS
contracts in place, which were tested and enforced and they worked
after some ironing during field trials.
Usually contract was bidirectional, with partner also using our
network for extending reach of their network, so both had incentive to
offer working QoS with network-edge translation of marking.

-- 
  ++ytti

Re: QoS for Office365

[Mark Tinka]

On 9/Jul/19 16:08, Joe Yabuki wrote:
> Hi all,
>
> Thanks for your replies,
>
> I'll rephrase just to clarify, our aim is to do QoS within our
> extended LAN (From remote sites to the Datacenter using the MPLS
> provider as transit) - and we can't use DIA for a security reasons...
>
> So arguably, we still need to mark/queue/police packets at the Edge of
> the Internet and on the remote site. For INTERNET we will throw
> bandwidth so it will not be a point of congestion (hopefully once we
> are in the Backbone's ISP we will go to Microsoft directly)

In that case, co-ordinate the QoS profile with your MPLS provider and
test both ends to make sure you receive what you send for on-net traffic.

Verifying that your MPLS provider is forwarding your traffic according
to the agreed-upon QoS profile is another thing.

As for the off-net traffic entering your network, well, you know about
that already...

Mark.

Re: QoS for Office365

[Mark Tinka]

On 9/Jul/19 16:01, Tom Beecher wrote:

>  
>
> But if that language was inserted into the contracts, and you can
> demonstrably prove it's not being done, enforcing contract terms
> should always be done. Depending on the strength of the remedy, could
> have been a lot of free service, enough financial incentive for them
> to MAKE it work correctly, or leverage to open renegotiations for more
> favorable terms for you.

Perhaps plenty of service credits. Anything else would just burn too
much time on either end for no practical outcome.

Mark.

Re: QoS for Office365

[Tom Beecher]

>
> 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.
>

Generally speaking, I agree that making QoS features work consistently on
an external network you do not control is a fool's errand.

But if that language was inserted into the contracts, and you can
demonstrably prove it's not being done, enforcing contract terms should
always be done. Depending on the strength of the remedy, could have been a
lot of free service, enough financial incentive for them to MAKE it work
correctly, or leverage to open renegotiations for more favorable terms for
you.

You know that in reverse they would have done the same to you. :)

On Mon, Jul 8, 2019 at 6:38 PM Warren Kumari  wrote:

> On Mon, Jul 8, 2019 at 5:50 PM Mark Tinka  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
>

Re: QoS for Office365

[Mark Tinka]

To quote from that URL:

    QoS only works as expected when implemented on all links between
callers. If you use QoS
    on an internal network and a user signs in from a remote location,
you can only prioritize within
    your internal, managed network.

Mark.

On 9/Jul/19 02:41, cyrus ramirez wrote:
> Implement Quality of Service in Microsoft Teams
> 
>
>   
>
>
>   
>
>
> Implement Quality of Service in Microsoft Teams
>
> Prepare your organization's network for Quality of Service (QoS) in
> Microsoft Teams.
>
>   
>
> 
>
>
>
> Sent from Yahoo Mail on Android
> 
>
> On Mon, Jul 8, 2019 at 12:47 PM, Mark Tinka
>  wrote:
>
>
> On 8/Jul/19 18:18, Jared Mauch wrote:
>
> >
> > Add bandwidth?
> >
> > QoS is a great tool when you’re constrained and must classify
> your critical traffic, but it’s not a substitute of getting enough
> capacity to offices.
> >
> > I have only applied QoS to voice traffic to ensure it gets
> through, the rest you need to budget for the bandwidth needs of
> the site.  The price of bandwidth likely isn’t insane in your
> market, but your budget may be.. I’ve found that most places won’t
> quote you a service for less than $1500 USD MRC.  I know you can
> get the incumbents to often deliver 1G service for $2k/mo in the
> US (and possibly cheaper).
> >
> > I’ve found a lot of people are still stuck in TDM mentality
> instead of just getting a 1G/10G service.
>
>
> In some cases, the motivation for these requirements is fueled by
> trying
> to outsmart your competitors.
>
> I just don't know of a reliable, contractual way that you can use
> QoS to
> say your DIA or IP Transit service is better than that of your
> competitor.
>
> Mark.
>

Re: QoS for Office365

[Mark Tinka]

On 9/Jul/19 01:00, Keith Medcalf wrote:

> Using Orifice 342 will hurt you.

Can't choose what my customers like :-).

Mark.

Re: QoS for Office365

[Radu-Adrian Feurdean]

On Mon, Jul 8, 2019, at 18:15, Joe Yabuki wrote:
> Hi all, 
> 
> How do you deal with QoS for Office365, since the IPs are subject to changes ?

For "Classic QoS" : you don't. At best you tell the customer it's done without 
actually doing anything (it very often works). If it doesn't, see previous 
answers (those reccomending bandwidth upgrade and correct capacity provisioning 
a.k.a. "Modern QoS").

Re: QoS for Office365

[cyrus ramirez via NANOG]

Implement Quality of Service in Microsoft Teams  
|  
|   
|   
|   ||

   |

  |
|  
|   |  
Implement Quality of Service in Microsoft Teams
 
Prepare your organization's network for Quality of Service (QoS) in Microsoft 
Teams.
  |   |

  |

  |

  


Sent from Yahoo Mail on Android 
 
  On Mon, Jul 8, 2019 at 12:47 PM, Mark Tinka wrote:   

On 8/Jul/19 18:18, Jared Mauch wrote:

>
> Add bandwidth?
>
> QoS is a great tool when you’re constrained and must classify your critical 
> traffic, but it’s not a substitute of getting enough capacity to offices.
>
> I have only applied QoS to voice traffic to ensure it gets through, the rest 
> you need to budget for the bandwidth needs of the site.  The price of 
> bandwidth likely isn’t insane in your market, but your budget may be.. I’ve 
> found that most places won’t quote you a service for less than $1500 USD MRC. 
>  I know you can get the incumbents to often deliver 1G service for $2k/mo in 
> the US (and possibly cheaper).
>
> I’ve found a lot of people are still stuck in TDM mentality instead of just 
> getting a 1G/10G service.

In some cases, the motivation for these requirements is fueled by trying
to outsmart your competitors.

I just don't know of a reliable, contractual way that you can use QoS to
say your DIA or IP Transit service is better than that of your competitor.

Mark.
  

RE: QoS for Office365

[Keith Medcalf]

Using Orifice 342 will hurt you.

Packet loss (the more the better) will only help you.

--
The fact that there's a Highway to Hell but only a Stairway to Heaven says a 
lot about anticipated traffic volume.


>-Original Message-
>From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Mark Tinka
>Sent: Monday, 8 July, 2019 15:50
>To: Robert Webb
>Cc: NANOG list
>Subject: Re: QoS for Office365
>
>
>
>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.
>
>
>>
>> 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.

Re: QoS for Office365

[Mark Tinka]

On 9/Jul/19 00:35, Warren Kumari wrote:

> 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.

I'll rephrase... you can't guarantee that a remote network will handle
your packets the way you intend.


> 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.

Agreed.

I would, though, say that I admire that you went as far as ringing up
contracts on the back of this.

Mark.

Re: QoS for Office365

[Warren Kumari]

On Mon, Jul 8, 2019 at 5:50 PM Mark Tinka  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

Re: QoS for Office365

[Mark Tinka]

On 8/Jul/19 22:01, adamv0...@netconsultings.com wrote:

> And yet the SD-WAN promising MPLS experience over the internet and other BS 
> sells like crazy ;)

Where have we seen that before...

Still waiting for the ATM port on my laptop :-).

Mark.

Re: QoS for Office365

[Mark Tinka]

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.


>
> 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.

RE: QoS for Office365

[adamv0025]

> Warren Kumari
> Sent: Monday, July 8, 2019 8:06 PM
> 
> On Mon, Jul 8, 2019 at 2:59 PM Mark Tinka  wrote:
> >
> >
> >
> > On 8/Jul/19 20:50, Warren Kumari wrote:
> >
> > > Depends -- I'd note that the OP said "How can we mark the trafic
> > > while keeping the security..." -- some people use the COS / DSCP
> > > bits to annotate packets with security information, and use that to
> > > make *security decisions* instead of using it to prioritize traffic.
> > > Now, I'm not saying that this is why the OP is asking (or that I
> > > think it is a good idea, because, well,  I don't think it is!), but
> > > it *is* a practice worth knowing about.
> >
> > Assuming we are discussing such packets traversing the public
> > Internet, a little tricky to expect IPP/DSCP values to remain intact
> > in the life of an Internet packet.
> 
> Goodness no -- I've only ever seen this done within a single network
> (including inside some tunnels); expecting this to work across the Big I-
> internet is crazypants time. I personally think that the idea itself is 
> stupid,
> but, well, their network, their rules, and it "works" for them.
> 
And yet the SD-WAN promising MPLS experience over the internet and other BS 
sells like crazy ;)

adam

Re: QoS for Office365

[Warren Kumari]

On Mon, Jul 8, 2019 at 2:59 PM Mark Tinka  wrote:
>
>
>
> On 8/Jul/19 20:50, Warren Kumari wrote:
>
> > Depends -- I'd note that the OP said "How can we mark the trafic while
> > keeping the security..." -- some people use the COS / DSCP bits to
> > annotate packets with security information, and use that to make
> > *security decisions* instead of using it to prioritize traffic. Now,
> > I'm not saying that this is why the OP is asking (or that I think it
> > is a good idea, because, well,  I don't think it is!), but it *is* a
> > practice worth knowing about.
>
> Assuming we are discussing such packets traversing the public Internet,
> a little tricky to expect IPP/DSCP values to remain intact in the life
> of an Internet packet.

Goodness no -- I've only ever seen this done within a single network
(including inside some tunnels); expecting this to work across the Big
I-internet is crazypants time. I personally think that the idea itself
is stupid, but, well, their network, their rules, and it "works" for
them.

W

>
> 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

Re: QoS for Office365

[Robert Webb]

I took the OP's request as for doing QoS at the edge of their network and
not necessarily the entire path.

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.

Robert

On Mon, Jul 8, 2019 at 3:00 PM Mark Tinka  wrote:

>
>
> On 8/Jul/19 20:50, Warren Kumari wrote:
>
> > Depends -- I'd note that the OP said "How can we mark the trafic while
> > keeping the security..." -- some people use the COS / DSCP bits to
> > annotate packets with security information, and use that to make
> > *security decisions* instead of using it to prioritize traffic. Now,
> > I'm not saying that this is why the OP is asking (or that I think it
> > is a good idea, because, well,  I don't think it is!), but it *is* a
> > practice worth knowing about.
>
> Assuming we are discussing such packets traversing the public Internet,
> a little tricky to expect IPP/DSCP values to remain intact in the life
> of an Internet packet.
>
> Mark.
>

Re: QoS for Office365

[Mark Tinka]

On 8/Jul/19 20:50, Warren Kumari wrote:

> Depends -- I'd note that the OP said "How can we mark the trafic while
> keeping the security..." -- some people use the COS / DSCP bits to
> annotate packets with security information, and use that to make
> *security decisions* instead of using it to prioritize traffic. Now,
> I'm not saying that this is why the OP is asking (or that I think it
> is a good idea, because, well,  I don't think it is!), but it *is* a
> practice worth knowing about.

Assuming we are discussing such packets traversing the public Internet,
a little tricky to expect IPP/DSCP values to remain intact in the life
of an Internet packet.

Mark.

Re: QoS for Office365

[Warren Kumari]

On Mon, Jul 8, 2019 at 12:31 PM Jared Mauch  wrote:
>
>
>
> > On Jul 2, 2019, at 5:18 PM, Joe Yabuki  wrote:
> >
> > Hi all,
> >
> > How do you deal with QoS for Office365, since the IPs are subject to 
> > changes ?
> >
> > How can we mark the trafic while keeping the security (I fear the marking 
> > based on TCP/UDP Ports since they are not without an additional risk coming 
> > from worms/virus using those ports for example, and doing that directly on 
> > the PCs doesn't seem to be the best solution) ?
>
>
> Add bandwidth?
>
> QoS is a great tool when you’re constrained and must classify your critical 
> traffic, but it’s not a substitute of getting enough capacity to offices.

Depends -- I'd note that the OP said "How can we mark the trafic while
keeping the security..." -- some people use the COS / DSCP bits to
annotate packets with security information, and use that to make
*security decisions* instead of using it to prioritize traffic. Now,
I'm not saying that this is why the OP is asking (or that I think it
is a good idea, because, well,  I don't think it is!), but it *is* a
practice worth knowing about.

One enterprise I've seen does:
firewall {
family inet {
   filter Egress {
term allow {
from {
prefix-list {
TrustedSubnets;
}
dscp af42;
}
then accept;
}
term default {
then {
encapsulate CaptiveGarden;
}
}
}
  }
}

They have some shim thingie on corporate machines which tags
"approved" traffic with AF42 (and also mark on switches from other
devices which should have Internet access), and everyone else gets
bumped to a captive portal / logging / scrubbing firewall thingie.
This is remarkably bletcherous, but (because?) you can do 'iptables -t
mangle -A FORWARD -j dscp --set-dscp-class  AF42' to tag all
packets...

W

>
> I have only applied QoS to voice traffic to ensure it gets through, the rest 
> you need to budget for the bandwidth needs of the site.  The price of 
> bandwidth likely isn’t insane in your market, but your budget may be.. I’ve 
> found that most places won’t quote you a service for less than $1500 USD MRC. 
>  I know you can get the incumbents to often deliver 1G service for $2k/mo in 
> the US (and possibly cheaper).
>
> I’ve found a lot of people are still stuck in TDM mentality instead of just 
> getting a 1G/10G service.
>
> - Jared



-- 
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

Re: QoS for Office365

[Mark Tinka]

On 8/Jul/19 18:18, Jared Mauch wrote:

>
> Add bandwidth?
>
> QoS is a great tool when you’re constrained and must classify your critical 
> traffic, but it’s not a substitute of getting enough capacity to offices.
>
> I have only applied QoS to voice traffic to ensure it gets through, the rest 
> you need to budget for the bandwidth needs of the site.  The price of 
> bandwidth likely isn’t insane in your market, but your budget may be.. I’ve 
> found that most places won’t quote you a service for less than $1500 USD MRC. 
>  I know you can get the incumbents to often deliver 1G service for $2k/mo in 
> the US (and possibly cheaper).
>
> I’ve found a lot of people are still stuck in TDM mentality instead of just 
> getting a 1G/10G service.

In some cases, the motivation for these requirements is fueled by trying
to outsmart your competitors.

I just don't know of a reliable, contractual way that you can use QoS to
say your DIA or IP Transit service is better than that of your competitor.

Mark.

Re: QoS for Office365

[Mark Tinka]

On 2/Jul/19 23:18, Joe Yabuki wrote:

> Hi all, 
>
> How do you deal with QoS for Office365, since the IPs are subject to
> changes ?
>
> How can we mark the trafic while keeping the security (I fear the
> marking based on TCP/UDP Ports since they are not without an
> additional risk coming from worms/virus using those ports for example,
> and doing that directly on the PCs doesn't seem to be the best solution) ?

Funny, I was just answering an internal question about this, last week.

As with all things Internet, my stance is if you don't have end-to-end
control, trying to do QoS is pointless.

That said, I believe it should be possible to apply some kind of
meaningful, end-to-end QoS together with Microsoft if you took up one of
their Express Route services, given that is considered a private,
premium service.

Mark.

Re: QoS for Office365

[Jared Mauch]

> On Jul 2, 2019, at 5:18 PM, Joe Yabuki  wrote:
> 
> Hi all, 
> 
> How do you deal with QoS for Office365, since the IPs are subject to changes ?
> 
> How can we mark the trafic while keeping the security (I fear the marking 
> based on TCP/UDP Ports since they are not without an additional risk coming 
> from worms/virus using those ports for example, and doing that directly on 
> the PCs doesn't seem to be the best solution) ?


Add bandwidth?

QoS is a great tool when you’re constrained and must classify your critical 
traffic, but it’s not a substitute of getting enough capacity to offices.

I have only applied QoS to voice traffic to ensure it gets through, the rest 
you need to budget for the bandwidth needs of the site.  The price of bandwidth 
likely isn’t insane in your market, but your budget may be.. I’ve found that 
most places won’t quote you a service for less than $1500 USD MRC.  I know you 
can get the incumbents to often deliver 1G service for $2k/mo in the US (and 
possibly cheaper).

I’ve found a lot of people are still stuck in TDM mentality instead of just 
getting a 1G/10G service.

- Jared