I defer to your nftables knowledge on the implementation, I am more interested in the reasons for making 492 a magic number...
Objectively it is more standard than paintbrush image.
Ah, yes, I completely ignored the factoid that we also need to deal with whatever heuristics games throw at their users to divine their connectivity quality or similar...
I thought of giving small UDP packets (1/3 size of 1492 pppoe)giving low latency priority (Voice). I'd really need guidance on DSPC marking and how to test tins latency
Might well be, my point is even true rfc8325 should not to be taken as gospel...
You have wifi typically at other end.
If you do that over wifi you incr#ase airtime budget 5-10x
Yes, unmarked traffic should go into Bulk according to the rules I've set since that won't cause delay for other marked traffic. Yes haha it's intended
I think you're right. I just ran a test, and AF21 ended up in the video tin. I'll update the UI accordingly.
2 Likes
Now, your network, your rules, so take what I say with a pinch of salt (and sorry for being repetitive, I likely already wrote something like this in this thread):
The way prioritisation works is, for every packet that is treated to a shorter (than average) queueing delay some other packet(s) are experiencing higher (than average) delay or even drops. If there are no packets available that can be delayed or dropped, prioritisation stops working. The consequence is IMHO that one should try to up-prioritize as few packets as possible. And to reach and maintain that state, I recommend to scrutinise each and every prioritisation rule you add closely, if and only if a rule (either alone or in combination with other rules) delivers a measurable improvement (aka lower latency and lower jitter) keep it, otherwise drop/deactivate such rules independent on how rational these appear. Also make sure to occasionally recheck existing marking heuristics, as these might have been tailored to a traffic profile of an application that might have changed in the interim.
3 Likes
I even have a note about this in the README:
2 Likes
I think you're right. That actually really messed up ingress latency on Wi-Fi
1 Like
@Hudra, you clearly are well aware of this, but for the benefit of QoSmate users here is a quick howto for figuring this out:
So here is where cake actually defines the mappings:
static const u8 diffserv4[] = {
0, 1, 0, 0, 2, 0, 0, 0,
1, 0, 0, 0, 0, 0, 0, 0,
2, 0, 2, 0, 2, 0, 2, 0,
2, 0, 2, 0, 2, 0, 2, 0,
3, 0, 2, 0, 2, 0, 2, 0,
3, 0, 0, 0, 3, 0, 3, 0,
3, 0, 0, 0, 0, 0, 0, 0,
3, 0, 0, 0, 0, 0, 0, 0,
};
and here is the handy decoder for symbolic DSCP/TOS names:
https://tucny.com/Home/dscp-tos
For AF21 we get
| A | B | C | D | E | F | G | H | I | J | K | L | M |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| TOS (Dec) | TOS (Hex) | TOS (Bin) | TOS Precedence (Bin) | TOS Precedence (Dec) | TOS Precedence Name | TOS Delay flag | TOS Throughput flag | TOS Reliability flag | DSCP (Bin) | DSCP (Hex) | DSCP (Dec) | DSCP/PHB Class |
| 72 | 0x48 | 01001000 | 010 | 2 | Immediate | 0 | 1 | 0 | 010010 | 0x12 | 18 | af21 |
So decimal 18 value in the table (or rather the 19th value in the array, as the first value is 0)
so AF21 maps to tin 2, which indeed is Video...
Mapping rules for the array
Value: 0 -> BestEffort
Value: 1 -> Bulk/Background
Value: 2 -> Video
Value: 3 -> Voice
4 Likes
Excellent note! That maybe merits being bolded 
Yes, thanks for the detailed explanation. I already checked this earlier, but I still wanted to test it again as a sanity check.
Done 
1 Like
Thanks @moeller0 like you've no idea how much I've been searching to get the implemented source code online. Anyways I'm not really good at C and C++ but by looking at the code seems like:
static u8 cake_handle_diffserv(struct sk_buff *skb, bool wash)
{
switch (skb_protocol(skb, true)) {
default:
/* If there is no Diffserv field, treat as best-effort */
return 0; <---------
}
}
static struct cake_tin_data *cake_select_tin(struct Qdisc *sch,
struct sk_buff *skb)
{
if (q->tin_mode == CAKE_DIFFSERV_BESTEFFORT)
tin = 0;
}
here unmark traffic goes to Best-Effort
static u32 cake_hash(struct cake_tin_data *q, const struct sk_buff *skb, int flow_mode, u16 flow_override, u16 host_override)
In this method flow is hashed into one of the queues within a tin to prevent one flow from monopolizing resources regardless of DSCP
struct cake_tin_data {
struct cake_flow flows[CAKE_QUEUES]; <-----
u32 backlogs[CAKE_QUEUES];
u32 tags[CAKE_QUEUES]; /* for set association */
u16 overflow_idx[CAKE_QUEUES];
struct cake_host hosts[CAKE_QUEUES]; /* for triple isolation */
u16 flow_quantum;
Each tin contains a separate array of flow queues (flows) #define CAKE_QUEUES (1024) to isolate traffic.
static struct sk_buff *cake_dequeue_one(struct Qdisc *sch)
{
struct cake_sched_data *q = qdisc_priv(sch);
struct cake_tin_data *b = &q->tins[q->cur_tin];
struct cake_flow *flow = &b->flows[q->cur_flow];
struct sk_buff *skb = NULL;
u32 len;
if (flow->head) {
skb = dequeue_head(flow);
len = qdisc_pkt_len(skb);
b->backlogs[q->cur_flow] -= len;
b->tin_backlog -= len;
sch->qstats.backlog -= len;
q->buffer_used -= skb->truesize;
sch->q.qlen--;
if (q->overflow_timeout)
cake_heapify(q, b->overflow_idx[q->cur_flow]);
}
return skb;
}
And at deque it applied Round Robin (WDRR) on queues, so each flow gets a fair share of the tin's bandwidth.
else if (flow->set == CAKE_SET_SPARSE_WAIT) {
struct cake_host *srchost = &b->hosts[flow->srchost];
struct cake_host *dsthost = &b->hosts[flow->dsthost];
/* this flow was empty, accounted as a sparse flow, but actually
* in the bulk rotation.
*/
flow->set = CAKE_SET_BULK;
b->sparse_flow_count--;
b->bulk_flow_count++;
After few seconds of bulk download, it assigns to Bulk tin. Above code is the trigger point where it dynamically detects the bulk flow & if the flow exceeds threshold from sparse to bulk based on factors like bulk_flow_count Cake puts it to Bulk tin.
=====================================
So, my understanding here is that:
- Default configs are pretty solid
- It only makes sense to DSCP mark only BULK and gaming traffic if you're sure of it. Bcz Cake handles the middle ground pretty well.
- Objective here is to minimizing queue congestion for Round Robin scheduling algo to handle small packets faster.
Do you agree?
2 Likes
Yes, it's not that RED is bad per se, it's just that we don't really have much evidence either way. If RED feels good then go for it. The way that RED operates during the bandwidth probes might be beneficial for the games bandwidth estimation methods or something. It's interesting that bfifo with small max delay can sometimes make the game refuse you a lobby. They are assuming people are running on their ISP router over whatever so that it probing only 800kbps or something would suggest a crap connection rather than a guaranteed low latency channel like we are giving. So we definitely have to accommodate their assumptions to some extent.
As people get better connections, giving a dedicated channel of a few megabits per second probably avoids all these issues. On my gigabit fiber I could put 50Mbps in gameup and gamedown without issue. Even if you have 100Mbps fiber you could do 10Mbps...
1 Like
Please be aware that in cake Bulk really is taylored for throughput over latency, so it is not all that suited for e.g. interactive traffic. That said if your rules work for you just ignore my musings.
Not as I understand that... the bulk here has nothing to do with the Bulk priority tin, but cake will already give sparse/new flows a small boost over flows already classified as bulk (I believe bulk flows are those where the queue does not fall empty in between servicing).
That indeed was one of cake's design goals, decent default values...
Well, wether you need to mark bulk for normal bulk traffic is not even clear, but say for a constantly running torrent client/seeded the Bulk tin would be quite helpful. Up prioritising is best when restricted to packets that (from the end user's view) benefit sufficiently from it, if, in your case, that is gaming traffic all fine.
I do not understand that argument, so if I am supposed to comment you would need to expand/elaborate on the description...
You are right. Small packets vs acks upgrade -maybe. Edit the qosmte.sh after this in a dimilar fashion:
cs0 or cs2 ->cs3
another approach on cheap
https://man.openbsd.org/pf.conf#set~2
1 Like