Is there a reason you want to mark DSCP on the router instead of the machine that generates the packets, is someone trying to misuse DSCP - setting all traffic to high priority?
If you play games on Windows, you could use Local Group Policy Editor to mark DSCP
https://support.microsoft.com/en-us/help/2733528/policy-based-qos-not-working-in-windows-7-clients
If you play games on a Linux distro, iptables is already supported and in addition you could use network namespace to apply the marking to individual processes/applications.
When marking DSCP on machines that generate the packets, you could apply the marking to individual applications so that if a low priority application (or a remote server) started using ports in 5000:5500 range, the traffic wouldn't be incorrectly prioritized.
I'd try egress only shaping first as ingress is tricky (UDP even more so) that sometimes it could make the situation worse. Ingress shaping is usually more about deprioritization - dropping/marking TCP packets to signal congestion. For egress only shaping you'd need to remove prioritization for source port 5000:5500.
Although your upload bandwidth is a little low as @moeller0 pointed out, I think it's still possible to reduce the jitter and latency further. If this is purely an outbound traffic congestion problem, it should be possible to shape the traffic to make it behave almost as if you were the only person using the connection. The jitter and latency could be caused by other traffic competing for the limited upload bandwidth if your game exceeded the bandwidth threshold. To address that, you'd need a prio qdisc (http://man7.org/linux/man-pages/man8/tc-prio.8.html) that implements strict priority policy so that your gaming traffic could be prioritized over all other lower priority traffic which means low priority traffic would only be sent if there's spare bandwidth not used by high priority traffic (it could result in starvation which normally wouldn't matter if it's temporary, e.g. web pages taking one second longer to load wouldn't matter as much as getting 200ms latency spikes in games). When I used this set up, jitter and latency spikes were completely eliminated, so when I was playing a game, it's impossible to tell whether there's a P2P (torrent) downloading going on as low priority traffic had almost no impact on high priority traffic. I think if you set it like this, it's possible that jitter and latency spikes could be reduced to the point that it's undetectable.
In addition to prio qdisc which prioritizes traffic, you would need another qdisc to limit the overall bandwidth, you could use hfsc or htb, here's an example of htb + prio https://stackoverflow.com/questions/45978104/linux-htb-prio-qdisc-sometimes-empty-prio-1-queue , this is a simple example that doesn't care about fairness.
You could keep the realtime bandwidth graph open (wan tab) while playing games http://openwrt.lan/cgi-bin/luci/admin/status/realtime/bandwidth , when you experience jitter or latency spikes, check the graph to see whether inbound or outbound traffic spiked, that would tell you whether you have an outbound congestion problem or an inbound one. Spikes could be short-lived, so you might have to check many times.