Are there any plans to move traffic shaper from PF to IPFW?



  • Possible pros:

    cons:
    Please add some, if you know any


  • Banned

    Yeah, the cons are that it'd require redoing very much the entire firewall.  ::)



  • Thank you doktornotor  for pointing it out.
    As I understand pfSense uses both PF and IPFW (https://forum.pfsense.org/index.php?topic=37457.msg196651#msg196651), is it impossible to delegate shaping only to IPFW?
    Only for FQ_CODEL, for example?
    I understand that if somebody wants "classic" shaping modes like HFSC, then there is only one way to do it and it'd require redoing very much like you said.
    Sorry for asking stupid questions anyway  ;D

    AFAIK original PF project came from OpenBSD and nowadays do not use ALTQ anymore, but lacks SMP even now, as I understand there is nothing changed regarding PF ALTQ use on FreeBSD for the last 3-4 years, am I wrong?



  • Firewall and network performance are getting a lot of attention within FreeBSD. Probably best to wait to see which way FreeBSD goes before making any large changes.


  • Banned

    @w0w:

    As I understand pfSense uses both PF and IPFW (https://forum.pfsense.org/index.php?topic=37457.msg196651#msg196651), is it impossible to delegate shaping only to IPFW?

    As noted there, pretty much the only part of pfSense using ipfw is the captive portal. (There are packages like HAProxy using it for client IP transparency, which is a can of worms on its own, but that's not relevant here.)



  • @doktornotor:

    As noted there, pretty much the only part of pfSense using ipfw is the captive portal.

    Captive portal and limiters, which I think are still using dummynet.



  • Yes, limiters are using IPFW and dummynet.
    'ipfw pipe show' gives clear answer on that question.



  • @Harvy66:

    Firewall and network performance are getting a lot of attention within FreeBSD. Probably best to wait to see which way FreeBSD goes before making any large changes.

    I don't think anybody in FreeBSD community wants to improve ALTQ and moving the entire PF to other queue system or built-in, like OpenBSD did — sounds more like "mission impossible" to me, but I hope I am wrong.

    If I am right, at the beginning, it would be good to use both shapers PF and IPFW but not in the same time on the same task.
    Just adding FQ_CODEL in the list and using it with IPFW pipes and altq disabled.



  • I wonder if developers of FreeBSD regret now importing PF, as at the time it happened it seemed ipfw days were numbered, it was a only a matter of time.

    However as it turns out PF went a long time without much been done to it even bug fixes, its getting some attention now but it will remain an old version of PF not the latest from openbsd.  Whilst ipfw has carried on and even now getting feature enhancements.

    It would not surprise me if ALTQ was ditched at some point in the future (in FreeBSD) but I think PF itself will remain as too many people use it and would be a lot of upset people if it got EOL'd.

    I personally much prefer PF over ipfw as a firewall, but thats just as the firewall, I never really used ALTQ at all until I got my pfsense box.



  • IPFW also supports setting up queues that can shape bidirectionally on a single interface. This makes shaping with multiple WANs/LANs possible.

    One of my pet peeves with pfSense is this limitation. OPNsense doesn't have this limitation as it uses IPFW:
    https://docs.opnsense.org/manual/how-tos/shaper.html#prioritize-using-queues



  • @ltctech:

    IPFW also supports setting up queues that can shape bidirectionally on a single interface. This makes shaping with multiple WANs/LANs possible.

    One of my pet peeves with pfSense is this limitation. OPNsense doesn't have this limitation as it uses IPFW:
    https://docs.opnsense.org/manual/how-tos/shaper.html#prioritize-using-queues

    pfSense already supports ipfw's dummynet with it's "traffic-shaping limiters", which is capable of solving the situation you describe: https://doc.pfsense.org/index.php/Limiters



  • Actually I have tested limiters with FQ_CODEL enabled and it works, but I did not notice any big difference, need more tests but have no time.


  • Rebel Alliance Developer Netgate

    The future isn't set in stone yet, I heard FreeBSD is removing ALTQ from -current soon. It may be gone from 12, or after. Not sure what the replacement might be. Having some form of QoS is essential, but ALTQ isn't going to be it for much longer. We're keeping an eye on options.



  • Just good reading
    http://bsdly.blogspot.com.ee/2011/07/anticipating-post-altq-world.html
    I will be happy to see "Enable FQ-CoDel" check box on limiters or "FQ-CoDel" selection on shaper type, where CODEL is already present in pfSense.



  • I also vote for FQ-CoDel



  • bear in mind freebsd (and also PFsense since thats based on freebsd), has not been following openbsd's PF for a long while, so this doesnt mean ALTQ is going anywhere.


  • Rebel Alliance Developer Netgate

    @chrcoluk:

    bear in mind freebsd (and also PFsense since thats based on freebsd), has not been following openbsd's PF for a long while, so this doesnt mean ALTQ is going anywhere.

    It does when FreeBSD says they're considering removing ATLQ.



  • any source for this info? can only find references to openbsd.

    If you are right and it does go, it be a shame as ALTQ with HSFC is the best shaper I have ever used for ingress.


  • Rebel Alliance Developer Netgate

    No public source (yet)



  • @chrcoluk:

    any source for this info? can only find references to openbsd.

    If you are right and it does go, it be a shame as ALTQ with HSFC is the best shaper I have ever used for ingress.

    In fact that it is the best for you it does not mean it could not be better or even already is, may be you do not use it nowadays. 
    Also the new subsystem that already came to openbsd to replace ALTQ may be even better.
    https://pdf.k0nsl.org/C/Computer and Internet Collection/2015 Computer and Internet Collection part 1/No Starch Press The Book of PF, A No-Nonsense Guide to the OpenBSD Firewall 3rd (2015).pdf
    page 118, 131
    In fact, it's "always HFSC".
    I think ALTQ do not disappear immediately from FreeBSD and it will be available for many years, but will not moving forward.
    I have seen some reddit user posts about openbsd 5.x pf working faster then freebsd one, even without SMP support, hard to believe anyway :)



  • whilst its good that they using HFSC (page 123 of the PDF), it seems to be a significant dumbing down of the flexibility, ALTQ allows much more granular control then what is detailed in that document.  But as I said before FreeBSD is now several years behind openbsd with no plans I am aware of to catch up but instead take their own development path, so openbsd should have no bearing on what FreeBSD does.  I now await for some kind of announcement based on what Jim has posted, as at some point they would have to inform the FreeBSD userbase of plans.



  • @chrcoluk:

    ALTQ allows much more granular control then what is detailed in that document.

    I am not some kind of ALTQ magician, so I should just to believe you, but in fact it is useless when you are on >4G network, it just won't work at all.



  • I do confess to not reading the entire document :) but the bit I read indicated there is no a longer a choice of shaper to use, its just HSFC, whilst currently one can choose between PRIQ,FAIRQ, HSFC and more.



  • @chrcoluk:

    I do confess to not reading the entire document :) but the bit I read indicated there is no a longer a choice of shaper to use, its just HSFC, whilst currently one can choose between PRIQ,FAIRQ, HSFC and more.

    HFSC new and old can do all the same like PRIQ, FAIRQ do, also you called HSFC the best you need, so what the problem?  ;D
    My dream in the beginning of the topic was not to remove something, but to add new algorithms on IPFW side, anyway it used already for limiters, so why not to move some shaper jobs to it and in future step by step moving from ALTQ to something better.



  • @w0w:

    @chrcoluk:

    I do confess to not reading the entire document :) but the bit I read indicated there is no a longer a choice of shaper to use, its just HSFC, whilst currently one can choose between PRIQ,FAIRQ, HSFC and more.

    HFSC new and old can do all the same like PRIQ, FAIRQ do, also you called HSFC the best you need, so what the problem?  ;D
    My dream in the beginning of the topic was not to remove something, but to add new algorithms on IPFW side, anyway it used already for limiters, so why not to move some shaper jobs to it and in future step by step moving from ALTQ to something better.

    Not quite true. Fair Queueing has no strict, technical definition. What HFSC defines as "fair" is not the same as what FAIRQ defines as "fair".



  • The true is that it can, but I did not say how well it do the same job  ;)
    I don't know what really FAIRQ do, but I've seen your post about FAIRQ

    Fair Queueing is per-byte fairness

    So yes, definitely it is not the same as HFSC if it's true.



  • @w0w:

    HFSC new and old can do all the same like PRIQ, FAIRQ do, also you called HSFC the best you need, so what the problem?  ;D
    My dream in the beginning of the topic was not to remove something, but to add new algorithms on IPFW side, anyway it used already for limiters, so why not to move some shaper jobs to it and in future step by step moving from ALTQ to something better.

    The problem is I think choice is king, what is best for me may not be best for someone else.

    Also for egress I find fairq+codel the best.  HSFC only best for ingress.



  • @chrcoluk:

    The problem is I think choice is king
    [over-quote deleted]

    It's not a problem.

    Giving us on the first steps in additional to exciting ALTQ use IPFW based shaping is better choice then nothing new. At least it giving you choice and ability to use "less knobs" shaper on modern 10G or other hardware, that do not support ALTQ and possibly never will. This is really giving you choice. Today you just can't use pfSense shaper on those 10G networks, even if it's not widespread.



  • of course if we have both I have absolutely no problem with that. :)



  • Those who are not afraid to experiment, welcome to https://forum.pfsense.org/index.php?topic=126637.msg699341#msg699341
    Thanks to qubit, everyone now can try playing with FQ_CODEL at least.