QoS for Office365
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
On Jul 2, 2019, at 5:18 PM, Joe Yabuki <joeyabukiyin@gmail.com> 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
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.
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<mark.tinka@seacom.mu> 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.
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 <https://docs.microsoft.com/en-us/microsoftteams/qos-in-teams>
Implement Quality of Service in Microsoft Teams
Prepare your organization's network for Quality of Service (QoS) in Microsoft Teams.
<https://docs.microsoft.com/en-us/microsoftteams/qos-in-teams>
Sent from Yahoo Mail on Android <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
On Mon, Jul 8, 2019 at 12:47 PM, Mark Tinka <mark.tinka@seacom.mu> 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.
On Mon, Jul 8, 2019 at 12:31 PM Jared Mauch <jared@puck.nether.net> wrote:
On Jul 2, 2019, at 5:18 PM, Joe Yabuki <joeyabukiyin@gmail.com> 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
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.
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 <mark.tinka@seacom.mu> 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.
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.
On Mon, Jul 8, 2019 at 5:50 PM Mark Tinka <mark.tinka@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
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.
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 <warren@kumari.net> wrote:
On Mon, Jul 8, 2019 at 5:50 PM Mark Tinka <mark.tinka@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
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.
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 <mark.tinka@seacom.mu> 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.
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.
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 <mark.tinka@seacom.mu> 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.
On Jul 9, 2019, at 07:19, Mark Tinka <mark.tinka@seacom.mu> 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.
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.
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 <jnford@uiowa.net>, Network Engineering, University of Iowa
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.
On Jul 9, 2019, at 9:19 AM, Mark Tinka <mark.tinka@seacom.mu> 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
On Tue, 9 Jul 2019 at 17:05, Tom Beecher <beecher@beecher.cc> 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
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.
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)?
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.
On Tue, 9 Jul 2019 at 17:37, Valdis Klētnieks <valdis.kletnieks@vt.edu> 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
On Tue, Jul 9, 2019 at 10:02 AM Tom Beecher <beecher@beecher.cc> 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 <warren@kumari.net> wrote:
On Mon, Jul 8, 2019 at 5:50 PM Mark Tinka <mark.tinka@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
-- 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
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-bounces@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.
On Mon, Jul 8, 2019 at 2:59 PM Mark Tinka <mark.tinka@seacom.mu> 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
Warren Kumari Sent: Monday, July 8, 2019 8:06 PM
On Mon, Jul 8, 2019 at 2:59 PM Mark Tinka <mark.tinka@seacom.mu> 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
On 7/8/19 4:01 PM, adamv0025@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
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.
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.
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 <nanog-bounces@nanog.org> 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.
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.
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 <nanog@nanog.org> 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 <nanog-bounces@nanog.org> 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.
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
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
On Tue, 9 Jul 2019 at 18:50, Tom Beecher <beecher@beecher.cc> 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
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 <saku@ytti.fi> wrote:
On Tue, 9 Jul 2019 at 18:50, Tom Beecher <beecher@beecher.cc> 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
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 <nanog@nanog.org> 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 <nanog-bounces@nanog.org> 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: marka@isc.org
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").
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... On Jul 2, 2019, at 17:18, Joe Yabuki <joeyabukiyin@gmail.com> 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
: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-ra... https://docs.microsoft.com/en-us/office365/enterprise/office-365-ip-web-serv... out of date? -Mike -- Michael J. O'Connor mjo@dojo.mi.org =--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--==--= "Nothing unreal exists." -Kiri-Kin-Tha's First Law Of Metaphysics
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-ra... https://docs.microsoft.com/en-us/office365/enterprise/office-365-ip-web-serv...
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 <https://docs.microsoft.com/office365/enterprise/azure-expressroute> for this specific case. /mark
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 <joeyabukiyin@gmail.com> 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
participants (24)
-
adamv0025＠netconsultings.com -
Alan Buxey -
Brandon Martin -
Brian Knight -
cyrus ramirez -
Edward Salonia -
Jared Mauch -
Jay Ford -
Joe Yabuki -
Joel Jaeggli -
Keith Medcalf -
Mark Andrews -
Mark Milhollan -
Mark Tinka -
Mike O'Connor -
Paul Thornton -
Radu-Adrian Feurdean -
Robert Webb -
Ross Tajvar -
Saku Ytti -
Steve Mikulasik -
Tom Beecher -
Valdis Klētnieks -
Warren Kumari