QoS on MX68 with 3P Managed Switches

[RumorConsumer]

I've been reading a bit about QoS management and am trying to suss out a few questions. 

https://documentation.meraki.com/MS/Other_Topics/QoS_(Quality_of_Service)

One is that it seems like there are a few different ways to deliver QoS. Right now I have my MX68 set to doing the standard set QoS rules that prioritizes realtime audio and video chat. 

Meraki seems to prefer this DSCP technology and also says they use DiffServ. So the way I understand it is that the MX puts DSCP info in the packet headers, and then its up to the switches to accurately carry out those wishes, basically? 

I use Netgear switches on my property and looking in the config I see this option that I had never thought to look at let alone change. I figured it was all happening in the MX. Should I make adaptations here in my switches? 

[KarstenI]

DSCP is the only QoS that can run end to end as the information is in the IP-header. Just make sure that the infrastructure is trusting it all the way. As to your Netgear, you could also trust .1p, but you lose information as you only have three bits for QoS instead of 6 bits in DSCP. And the .1p header is only available if you also have .1q tagged packets. So make sure that all Vlans on the trunk are tagged. DSCP will be easer as you also do not have to deal with conversion from L2-COS to L3-DSCP and vice versa.

[RumorConsumer]

Thanks @KarstenI 

So then being totally new to this protocol and particular standard system, would you say that I need to enable this feature manually as you can see in the screenshot? Does it somehow receive instructions from my router when I turn on DSCP?

[Bruce]

@RumorConsumer, QoS is a big topic. If you're talking a home or small business network and you're running gigabit Ethernet or better across your network then its unlikely QoS will give you any benefit on the LAN (not inconceivable, but unlikely). QoS doesn't apply to traffic on the internet, and generally its just ignored, so the best you can do is prioritise traffic as it egresses the MX towards the internet. But this doesn't change the way returning traffic (i.e. downloads) is treated and this is generally the bulk of the traffic.

As @KarstenI stated, Meraki only support DSCP (Differentiated Services Code Point) for QoS and this is carried end-to-end in the Layer 3 header. DiffServ (or Differentiated Services) is just the methodology by which the QoS is implemented, services are differentiated (i.e. by a code point or marking) and this is then processed hop by hop, on a packet by packet basis throughout the network. The alternative is IntServ (or Integrated Services) where session setup messages are exchanged between the endpoints and processed at the intermediate hops to confirm bandwidth is available and to establish a guaranteed 'channel' for the communications to use.

For QoS for be effective it generally needs to be implemented from end-to-end. The access port that the client connects to should mark the traffic, or better still, if the client can mark the traffic itself then the access port should trust (and use) these markings. This trust must exist all the way across the network to the server, and then the QoS markings the server uses should be trusted (and used) on the way back.

Since the Meraki uses only DSCP then your best bet is to use this across your entire network.

The link you reference is for MS QoS, the MX is similar but different. For a start it only has three priority queues (low, normal, high) plus one low latency queue for DSCP EF packets. Also, so far as I'm aware, it doesn't have any default mapping of DSCP to queue (other than the low latency queue) everything is just put into the 'normal' queue. You need to map your applications to the appropriate queue (and remark DSCP if you want) using the SD-WAN and Traffic Shaping configuration page. There is no way to map a DSCP marking to a particular queue (other than the DSCP EF marking, which is built-in). This prioritisation is explained here, https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/SD-WAN_and_Traffic_Shaping and here, https://documentation.meraki.com/MX/Firewall_and_Traffic_Shaping/Using_Packet_Prioritization_on_a_Tr....

In my opinion however, if you're just using the MX for internet access then you'll see limited (if any) benefit in changing the queues as this is only a local configuration and really doesn't impact the downstream (i.e. from the internet) traffic, which is where the bulk of the traffic is.

[RumorConsumer]

@Bruce 

Gotcha - so dont worry about it is one of the best answers I could hope for. 

[RumorConsumer]

@Bruce What if I was running a retreat center with 30 regular residents who all had computers and iPhones and were all in some version of telecommunication all day long?

[KarstenI]

To add to @Bruce extensive answer and your comments:

I would not always ignore it completely. Trusting DSCP (and making sure the marking is not removed) is often only a little step in the GUI and I would set it accordingly just to "have it clean" and make sure that the marking gets to the point where you need it most: On the MX where the traffic is going from gigabit to mostly much lower bandwidth. On the internet itself there is no QoS that is honouring the markings. But on your MPLS WANs you often have QoS after inserting some extra coins. Each device needs to be setup individually in a similar and compatible way as the router will not tell other devices like the switch what to do.

Bruce also mentioned IntServ. That was just for education. Ignore it for your implementation as it is practically not used. The problem of IntServ is that it needs a state database on the intermediate devices. And no ISP wants to waste money on the resources needed for this. In IntServ there would be a signalling as you asked for.

Regarding who sets the markings:

It could be the endpoint, but you have to evaluate if that endpoint is really trusted. If your smartphones are MDM-managed, you probably can trust the phone and you want to use the markings as they are also available when traffic is sent from the device to the access-point.

But what about PCs? You do not want a user to mark all his bulk traffic as super important and kill your voice. There you have a Trust-boundary on the switch und the switch could set the markings on the packet (if the switch supports this feature).

For your retreat center, I would definitely make sure that the QoS is set up correctly.

[Bruce]

@RumorConsumer, 30 residents all running some form of video collaboration  application simultaneously probably isn’t more than 150Mbps. But throw in some 4K UHD Netflix streaming (assuming they’re all using at once) and you might be needing 750Mbps. If this was the case then I’d potentially be looking at using QoS to provide a better experience on the video collaboration application.

But if your internet connection can’t pull 750Mbps of Netflix then there is no point worrying about it on the LAN, this is why you need to understand your traffic. If there was that much Netflix then it’s mostly one way too, and unfortunately in the direction you can’t do much about... so consider the direction of the flows too. In my opinion QoS is a bit of a black art. Somethings you can definitely see benefit from it, like traditional IP phone systems, video conferencing systems, or a business critical app or two, and you can set them up from the start, but often beyond that you need to monitor the network and listen to user experiences and adjust the QoS appropriately.

A lot of modern web applications deal with congestion reasonably well these days and so work without any QoS at all - we’ve come a long way from Microsoft OCS.

[KarstenI]

You see @RumorConsumer with QoS there are always different opinions ... 😉

[Bruce]

@KarstenI, yep, QoS: an art form we can all disagree on 😀

[RumorConsumer]

@KarstenI  @Bruce  Haha thank you both. This is great. My bandwidth is rarely saturated (250x250 fiber) so Im going to not worry about it. Sounds like thats the suggested path at least for now.