You mention several different topics. Some quick thoughts:
-
/tool/netwatch with icmp monitors can monitor latency/RTT, and a script can modify PBRs to steer new connection over different route. You can use interval/count to spread the test over a long period so the netwatch calculation isn’t based on some instantaneous reading. And you can have multiple netwatch too. But generally speaking netwatch is what you got “built in”, so if you can use it, likely the best IMO.
-
For nDPI… I have not tried this… But why not just run nTop and along with its NetFlow collector as a container? While indirect, RouterOS can NetFlow data to nTop. And, with nTop running, the collected data from nDPI/nTop could be periodically exported to JSON or CSV, and be imported into RouterOS array and used in a netwatch script to make a routing decision.
-
One limit your up against in PBR and netwatch is neither can use /ip/firewall/address-list – /routing/rule only take raw IP/subnet, not RouterOS “lists”. I believe you could use mangle rules to put them into a routing table first, and then have PBR match on the routing table (and potentially change it). But that begs the question if you need fine-grain control, firewall mangle rule are more flexible since they have the full compliment of matchers, while PBR is limited just src/dst address/etc.