QoS end to end

[Cajuntank]

Just need a little validation check against something I am implementing yet feel like I am losing something as well. What I mean by that is, I have in my environment, an edge firewall (this is where my users get their primary Internet from), a core firewall (that is acting also as my core router for my private WAN and firewall for my datacenter servers), and my site firewalls. Most of my security inspection is happening at the site firewalls. Since those traffic flows have now been inspected at the site level, I had no inspection for that traffic at the core if it went to the edge, again with no more inspection at the edge (only inspection was for some segmented VLANs off the core to my datacenter servers, etc...). 

Now that I want to implement QoS/traffic shaping on some traffic (Apple and Microsoft blowing up my bandwidth), my assumption is that I am going to have to implement traffic shaping also end to end... so edge, core, and site. Am I thinking correct on this? I feel like this is correct, but I now have to "inspect" certain traffic flows on my core and edge which will slow that traffic down some, so I lose in that regard (speed and resource usage on those subsequent appliances). Thoughts?

[Toshi_Esumi]

I don't have time to dig into the detail. But one thing I can comment on the subject is QoS is always works locally. It never communicate or negotiate with the other end the traffic is coming/going from/to. It just classify the traffic then if incoming, only thing it does is either passing or dropping (policing), and if outgoing, it would be queued, scheduled for delivery to the port. Everything in local.

That's the QoS. For FW inspection, it's either allowed or denied. There is no intentional delaying or scheduling. That's local operation as well. Nothing is end to end.

Toshi   

[Cajuntank]

The "delay" I speak of is the adding of application inspection, even if it's just monitoring to a firewall policy so that a traffic shaping policy, based on Application will work. If I had before a fw policy that had zero inspection then added inspection just so that the traffic shaping policy would work (again, based on application), then that would impose a resource and performance hit of some kind. And maybe from an aspect of the traffic I am wanting to shape/police, that shaping at the edge is all I really need maybe...just still wondering and thinking.

[Cajuntank · Accepted solution]

Ok, I think I figured this out with some Ai assistance. ISFW to Core, shaping more for internal processes (internal client to server, internal server to server priority bandwidth, etc...). Not really meant to shape Internet traffic like Office365 or online business applications, guest Internet, etc... This makes sense, so while an application like VoIP might need end to end QoS and markings to remain in high priority queues, Internet business apps and guest traffic would only need shaping/policing at the Edge.

[Toshi_Esumi]

Marking (like DSCP) is not guaranteed to reach the other end intact over the internet. Unless it goes over VPNs, which encapsulate the tagging/marking.

Toshi 

[Cajuntank]

In my situation, it is. My ISP is also my VoIP provider, so they retain DSCP markings to their servers and back to me as long as my equipment retains those markings along its internal path. That part of it has been confirmed and proven.