Priority queuing - can someone clarify?
-
Hi,
I haven't yet tried pfsense out. I'm currently using m0n0wall which I'm quite satisfied with, considering my needs. But I have a couple of questions regarding the new traffic shaping capabilities of pfsense.I'll start by saying I am not using VoIP at all. The reason I want to use traffic shaping is that We have about 10 tenants using our connection as well as 6 of us, so I want alot of control over the traffic so that the internet performs well even when the little piggies are downloading like crazy.
That said, I wan't too satisfied when I found out that using queues (with m0n0wall) means that you set aside a proportion of the bandwidth for certain types of packets - and even if the rest of your bandwidth is free, the queue can fill up and will only use that proportion of your bandwidth. The thing is, I dont want to statically allocate bandwidth because I always want to use all the bandwidth I pay for.
These new types of queuing methods - how exactly do they work? do they really assign a priority to the packets, so that packets I deem important will always be moved to the front of the queue, regardless of how little or how much bandwidth they consume, and regardless of how little or how much bandwidth other services are consuming?
Can someone please explain the new types of queuing and how they work, in detail? Also, what are the known bugs in the latest version of the software?
thanks,
Jerome
-
there is not going to be a simple answer on this one but you will have to do some reading.
http://www.openbsd.org/faq/pf/
http://www.openbsd.org/faq/pf/queueing.html
I'm not sure as I havn't kept up to date on pfSense but I think it is know on a FreeBSD platform running
ipfirewall
ALTQ traffic shaping
and also openbsd's PF. Those links i linked above is basically telling you how to do it command line but offer some great documentation. I would also recommend the book Firewalls with OpenBSD. -
Hi,
I haven't yet tried pfsense out. I'm currently using m0n0wall which I'm quite satisfied with, considering my needs. But I have a couple of questions regarding the new traffic shaping capabilities of pfsense.I'll start by saying I am not using VoIP at all. The reason I want to use traffic shaping is that We have about 10 tenants using our connection as well as 6 of us, so I want alot of control over the traffic so that the internet performs well even when the little piggies are downloading like crazy.
That said, I wan't too satisfied when I found out that using queues (with m0n0wall) means that you set aside a proportion of the bandwidth for certain types of packets - and even if the rest of your bandwidth is free, the queue can fill up and will only use that proportion of your bandwidth. The thing is, I dont want to statically allocate bandwidth because I always want to use all the bandwidth I pay for.
These new types of queuing methods - how exactly do they work? do they really assign a priority to the packets, so that packets I deem important will always be moved to the front of the queue, regardless of how little or how much bandwidth they consume, and regardless of how little or how much bandwidth other services are consuming?
Can someone please explain the new types of queuing and how they work, in detail? Also, what are the known bugs in the latest version of the software?
thanks,
Jerome
The pfsense shaper uses altq and we can have a bandwidth reserve as well as an upper limit. The reserve is exactly how it sounds - it'll guarantee a queue X amount of bandwidth. Upper limit will put a ceiling on the traffic that queue is allowed to use. By default we set all queues to have a 1K reservation (yeah, low…but user modifyable) and no upperlimit. Priorities are set on the queues, so that higher priority queues have preference for traffic if there's competition for bandwidth.
--Bill
-
By default we set all queues to have a 1K reservation (yeah, low…but user modifyable) and no upperlimit
billm, a small question.
What is then "Choose the amount of bandwidth for this queue " ?
I have noticed that pfsense set 1% as default for those queues it create. -
By default we set all queues to have a 1K reservation (yeah, low…but user modifyable) and no upperlimit
billm, a small question.
What is then "Choose the amount of bandwidth for this queue " ?
I have noticed that pfsense set 1% as default for those queues it create.a bug in the pf parser - we have to specify bandwidth to that parameter even in HFSC, but it's not used. Only the realtime limit is used. I'll pull that from the display if HFSC is chosen as the scheduler (RELENG_1 is locked to HFSC, HEAD has both HFSC and CBQ available). Thanks for the reminder :)
–Bill
-
a bug in the pf parser - we have to specify bandwidth to that parameter even in HFSC, but it's not used. Only the realtime limit is used. I'll pull that from the display if HFSC is chosen as the scheduler (RELENG_1 is locked to HFSC, HEAD has both HFSC and CBQ available). Thanks for the reminder :)
–Bill
Ok.. hrm. If you remove the display that won't be a problem, but if you remove the option to specify the bandwidth, the shaper will no longer work for me. I setup custom shaping where I have 6 parent queue as children to the root queues, their children use the parent's queue bandwidth parameter to calculate their realtime, linkshare and upperlimit. That wouldn't be a problem for those who use the wizard exclusively. Also bandwidth is only ignored if a linkshare is specified, they are used interchangeably (except of course in realtime, etc.. calculation, only the bandwidth of the parent queue is used for that) so if linkshare isn't specified the bandwidth is used as the m2 value to determine the queue's share of the bandwidth. Hard limiting bandwidth will throw of the calculations on my queues. I have been able to verify this in practice and by reading altq's & hfsc code in the FreeBSD source tree. So i'll be a happy person if the option isn't removed. ;), The display? no problem.
-
Sounds like yet another case for the "Advanced" settings screens that keep getting tossed around.
IE: hide the option from the GUI unless a "Advanced" button is clicked somewhere.
-
a bug in the pf parser - we have to specify bandwidth to that parameter even in HFSC, but it's not used. Only the realtime limit is used. I'll pull that from the display if HFSC is chosen as the scheduler (RELENG_1 is locked to HFSC, HEAD has both HFSC and CBQ available). Thanks for the reminder :)
–Bill
Ok.. hrm. If you remove the display that won't be a problem, but if you remove the option to specify the bandwidth, the shaper will no longer work for me. I setup custom shaping where I have 6 parent queue as children to the root queues, their children use the parent's queue bandwidth parameter to calculate their realtime, linkshare and upperlimit. That wouldn't be a problem for those who use the wizard exclusively. Also bandwidth is only ignored if a linkshare is specified, they are used interchangeably (except of course in realtime, etc.. calculation, only the bandwidth of the parent queue is used for that) so if linkshare isn't specified the bandwidth is used as the m2 value to determine the queue's share of the bandwidth. Hard limiting bandwidth will throw of the calculations on my queues. I have been able to verify this in practice and by reading altq's & hfsc code in the FreeBSD source tree. So i'll be a happy person if the option isn't removed. ;), The display? no problem.
Argh…care to show me how bandwidth is being used??? All my testing showed the bandwidth keyword on the queue statement to be required, but unused in HFSC, only upperlimit was used. Damn this ALTQ stuff is pissing me off - I guess I didn't catch that the bandwidth setting was used to calculate stuff on the queues, I thought only upperlimit affected it with HFSC (and I've read through the ALTQ code numerous times...doh)
--Bill
-
yeah right here..
/* if link_share is not specified, use bandwidth */
if (opts->lssc_m2 == 0)
opts->lssc_m2 = pa->bandwidth;if ((opts->rtsc_m1 > 0 && opts->rtsc_m2 == 0) ||
(opts->lssc_m1 > 0 && opts->lssc_m2 == 0) ||
(opts->ulsc_m1 > 0 && opts->ulsc_m2 == 0)) {
warnx("m2 is zero for %s", pa->qname);
return (-1);
}/src/contrib/pf/pfctl_altq.c line 700.
Its uses Bandwidth for m2 when linkshare is not specified. Thats what I have been using.OK. Try this for a test. setup two queues. don't specify a realtime or linkshare. give one a bandwidth of 100K and the other 50K (or 2%, 1%)
If the link isnt being used and you flaten those queues they share the bandwidth in a 2/3:1/3 ratio. At least that was the expected outcome and that was the result, for me. I think we should consider Scott's suggestion if the bandwidth option is to be removed as an HFSC option to prevent confusing. But I hope this kinda made it a bit clearer.Another interesting thing that might be related to this topic: Priority isn't used or considered in HFSC algorithm when deciding which queue to dequeue (look at the dequeue method in altq_hfsc.c that schedule packets). This might get a little technical, but HFSC selects a queue with the smallest vt (virtual time) and dequeue it.. vt is the difference between now (the time the queue was dequeued) and the calculation of the time (in the future) the packet at the head of the queue is suppose to be scheduled. If u actually draw the service curve its very easy to calculate the vt, just by using x-axis as the time unit. This means a queue with a more inclined slope will mostly likely have a smaller vt. Its actually very neat algorithm that doesn't use priority to do packet scheduling.. Which makes me wonder about the priority option on the queues :-\ maybe I missed something?. Anyways as I was saying.. priority doesnt count… its all there in the code to figure out how this thing work. Hope I didnt add to the confusion. :-\
-
yeah right here..
/* if link_share is not specified, use bandwidth */
if (opts->lssc_m2 == 0)
opts->lssc_m2 = pa->bandwidth;if ((opts->rtsc_m1 > 0 && opts->rtsc_m2 == 0) ||
(opts->lssc_m1 > 0 && opts->lssc_m2 == 0) ||
(opts->ulsc_m1 > 0 && opts->ulsc_m2 == 0)) {
warnx("m2 is zero for %s", pa->qname);
return (-1);
}/src/contrib/pf/pfctl_altq.c line 700.
Its uses Bandwidth for m2 when linkshare is not specified. Thats what I have been using.OK. Try this for a test. setup two queues. don't specify a realtime or linkshare. give one a bandwidth of 100K and the other 50K (or 2%, 1%)
If the link isnt being used and you flaten those queues they share the bandwidth in a 2/3:1/3 ratio. At least that was the expected outcome and that was the result, for me. I think we should consider Scott's suggestion if the bandwidth option is to be removed as an HFSC option to prevent confusing. But I hope this kinda made it a bit clearer.Oh yeah, MUCH clearer. I actually looked at that paste a couple times before it became apparent. Ouch. I believe 0Kb is what we should be setting (I'm not 100% sure that parses in FreeBSD - I know it does in Open). I'll work on fixing that so that we can remove the dual usage of bandwidth/upperlimit. If I work it that way, you OK with bandwidth disappearing if HFSC is selected as the scheduler?
Another interesting thing that might be related to this topic: Priority isn't used or considered in HFSC algorithm when deciding which queue to dequeue (look at the dequeue method in altq_hfsc.c that schedule packets). This might get a little technical, but HFSC selects a queue with the smallest vt (virtual time) and dequeue it.. vt is the difference between now (the time the queue was dequeued) and the calculation of the time (in the future) the packet at the head of the queue is suppose to be scheduled. If u actually draw the service curve its very easy to calculate the vt, just by using x-axis as the time unit. This means a queue with a more inclined slope will mostly likely have a smaller vt. Its actually very neat algorithm that doesn't use priority to do packet scheduling.. Which makes me wonder about the priority option on the queues :-\ maybe I missed something?. Anyways as I was saying.. priority doesnt count… its all there in the code to figure out how this thing work. Hope I didnt add to the confusion. :-\
I'll poke at the code - I swear priority made a difference for me, maybe I had something else selected at the time. If you use linkshare, priority stops working - again, tested - although at the time I think we still had that infernal ALTQ_NOPCC bug that was affecting the timer on the Soekris boxes.
This convo might be better off on the dev list, I don't check the forums that often :)
–Bill
-
If I work it that way, you OK with bandwidth disappearing if HFSC is selected as the scheduler?
This convo might be better off on the dev list, I don't check the forums that often :)–Bill
Ok.. I'll move this to the dev list later today when I wake up :).