IMHO that is one of the few decent settings. (This is also how DSCP usage could have been expedited, by not defaulting to BestEffort, so that doing nothing is a decent setting)
However I think that 3 tiers hit the sweet spot and there I think defaulting to the middle tier while allowing to selectively down- and up-prioritize a few selected traffic-aggregates is a pretty decent generic hierarchy.
Defaulting to Bulk is decent if you have important traffic that is well above the 50 or 25 priority capacity share the higher tiers in diffserv3 and diffserv4 offer (but this is admittedly a work around gor cake's fixed capacity share percentages per tier).
If you know the remote IP address for such traffic (e.g. 1.1.1.1) you can also check on the router's command line:
# outgoing
tcpdump -i pppoe-wan -v -n 'ip and (ip[1] & 0xfc) >> 2 != 0' and dst 1.1.1.1
# incoming
tcpdump -i pppoe-wan -v -n 'ip and (ip[1] & 0xfc) >> 2 != 0' and src 1.1.1.1
Because the actual DSCP bit patterns carry no meaning by them selves, what matters is the per-hop-behaviour, and for cake really all DSCPs that map to the same priority tier are effectively identical... it does not matter one iota what IETF RFCs describe as PHBs for a specific DSCP, if ou use cake all that matters is what cake does.
In theiry the DSCP pattern might matter upstream, but in all likelyhood your ISP is going to remark or at least ignore DSCPs you set. (Downstream from your router, it can matter when you use WiFi WMM, but there OpenWrt allows to set specific qos_maps that allow to steer individual DSCPs into the 4 WiFi access classes selectively)
hi Francisuk i use cs4 çar i play in cable and the dscp are only letters and numbers that are with cake defined in advance for the 4 boxes as moeller0 often repeats cs4 and ef are the same they will go in voice tin
@moeller0 I replaced your command with wan and destination ip but no traffic
If anyone can share a (small) PCAP that is appreciated. Please send it to me at jason_livingood@comcast.com so I can convince my dev team this is a persistent issue.
@lynxthecat - In general I have assumed that folk using the dual-* options were not setting nat in both directions. Triple-isolate should end up being the best choice with the nat option enabled. IMHO.
glad y'all are taking a look at it. Given a wifi bottleneck, CS1 markings will (IMHO), on any of it, will severely deprioritze CS1 wifi traffic on a busy network. I have seen 100s of ms, just from that impact on the wifi scheduler.
it cannot. so the nonat setting was kind of an error. I wish very much that we had left nat on by default in cake. I am responding to his recent commit turning nat on by default.
How that? IIRC triple is a clever trick if the directionality is not known, if directionality is known (and masquerading can by peeked into) then dual-srchost on egress and dual-dsthost on ingress gives per internal-IP fairness. triple-isolate will for normal traffic mixed essentially give something similar, but:
a) much harder to describe/predict on a packet-by-packet bases
b) will not work as expected in a number of simple test cases
So my advice has always been, if directions are known and masquerading is used use `nat dualxxxhost', if that is incorrect, please elaborate...
Also note that @lynxthecat for the time being has left OpenWrt forum; his posts are labelled anon10117369. He is still active on his github page and probably will respond to issues.
I think nonat is okay, AND I fully agree we should have defaulted to nat...
Update: the config error was identified in a few places, fix is ready, soak testing in 1 - 2 weeks and then deployment to complete in the early part of July. I'll try to remember to post back here when we're done. Thanks again to this list for the heads up!
