On Thu, 12 Apr 2018, Mikael Abrahamsson wrote:
I am also going to test a 3 queue setup, where each of these groups of DSCP values would go into different queues where LE would perhaps be assured 5% of BW and the rest split evenly between a BE and "everything else" queue. If I did that, I would probably not start dropping LE traffic until 10-20ms buffer fill.
I tried the following configuration which yielded expected results. Good thing here is that if you fill up BE and run some !BE (mikabr-rest class) then it basically doesn't get any added delay at all.
There were no hits on class-default, I just keep it there in case there is some traffic that won't be matched by the others. I tried speeds down to 10 megabit/s, where the BE RED profile causes significant buffer delay, up to 30-40ms with 10 concurrent TCP sessions. So these values are not "one size fits all", but they're at least much better than FIFO with huge buffers and LE is well controlled compared to the other traffic.
Again, I'm aiming to write up something about this for people to take to replace their overbuffered FIFOs they might have towards customers today, not produce something that is wonderfully great, but not widely supported in current hw.
policy-map OUT-QOS-SERVICE-1-2011 class mikabr-BE random-detect 10 ms 1000 ms bandwidth percent 40 ! class mikabr-LE random-detect 10 ms 1000 ms bandwidth percent 5 ! class mikabr-rest random-detect 10 ms 1000 ms bandwidth percent 40 ! class class-default bandwidth percent 5 ! end-policy-map policy-map OUT-QOS-1-2011 class class-default service-policy OUT-QOS-SERVICE-1-2011 shape average 400 mbps 100 us class-map match-any mikabr-BE match dscp 0 2-7 end-class-map ! class-map match-any mikabr-LE match dscp 1 8 end-class-map ! class-map match-any mikabr-rest match dscp 9-63 end-class-map -- Mikael Abrahamsson email: swm...@swm.pp.se _______________________________________________ aqm mailing list firstname.lastname@example.org https://www.ietf.org/mailman/listinfo/aqm