What improvements would you like to see in traffic-shaper GUI?
-
A way to be able to set interval and target for CoDel would be nice. The default values are based on 100ms RTTs. I find that pretty much all of my TCP connections are under 60ms, so a 60ms interval with 3ms target would be more appropriate.
The bufferbloat mailing list said interval should be your RTT for your 95th-99th percentile of connections and your target should be 5% of your interval. Of course it's possible for your target to get too low for one reason or another, so up to 10% is also fine, but 5% is the general rule.
-
https://forum.pfsense.org/index.php?topic=63531.0
-
I'm curious how limiters affect bufferbloat. They must be using buffers and they are a choke point. Unless they have very small buffers, they could be a source of bloat. If the buffers are too small, they could be a source of packet-loss for bursting.
The fq_CoDel folks have mentioned that hashing connections on the edge should be done on 5 tuple, src+dst+ports+somethingelse, aggregate uplinks that deal with flows from many users should hash based on just IP addresses. A fair queue that only hashes on IP addresses would evenly distribute bandwidth based on IP addresses.
-
If the FairQ scheduler works well, a dead simple wizard that you enter in your up/down bandwidth, and it configures your interfaces and enabled FairQ. Some how people don't understand checking a box, selecting a drop down, and setting your bandwidth and need their hands held a bit. Make this a simple "anti bufferbloat" wizard.
The default traffic shaping wizard makes way too many child queues. I think my current setup is probably a good place to start.
HFSC
qHigh 40% LS - ICMP, games, DNS, NTP, SSH, etc
qNormal 40% LS Web(80/443/8080), VPN, etc
qDefault 20% LS All unknown stuff
qACK 20% RT 0% LSI'm also thinking of an alias for qHigh that will include a list of IP addresses for Voice chat and game servers because many of these do not run on standard ports.
I also have a floating rule at the top that matches all TCP and sets their qACK, this way all TCP connections, no matter what, will at least have qACK set.
You could possibly create two sub-queues under qDefault, one for TCP and another for UDP and make them a 50/50 split. The reasoning for this is UDP traffic tends to be low bandwidth but latency sensitive and TCP traffic tends to consume all available bandwidth. By separating them, you should be able to isolate UDP from the jitter inducing damage of greedy TCP streams. The default queue would then be qTCP under qDefault.
Just some ideas to play with.
The only functional difference (that I found) between FAIRQ and HFSC is the processing power needed. Both are Fair Queueing algorithms, but FAIRQ (an implementation of a SFQ algorithm) uses a simpler method of separating the flows which occasionally causes the fairness to be imperfect (hash collisions).
Read the Stochastic Fair Queueing paper to see if it offers any other advantages over other Fair Queueing algorithms that I may have missed.
I think the wizard makes too many default queues as well. For the sake of simplicity, something like UDP, High Pri TCP, Low Pri TCP, and ACK (only for High Pri TCP) gets my vote. Though, it would be great to have a wizard that created enough rules to cover 99% of users, including NTP, DNS, torrents, etc, etc.
-
A way to be able to set interval and target for CoDel would be nice. The default values are based on 100ms RTTs. I find that pretty much all of my TCP connections are under 60ms, so a 60ms interval with 3ms target would be more appropriate.
The bufferbloat mailing list said interval should be your RTT for your 95th-99th percentile of connections and your target should be 5% of your interval. Of course it's possible for your target to get too low for one reason or another, so up to 10% is also fine, but 5% is the general rule.
Ah, yes. I kinda forgot about this.
Instead of direct access to interval/target, maybe a script that auto calculates?
I dunno if access to these values should be hidden or not. 99% of people have no reason to change it. Even with my 768Kbit upload, the pfSense CoDel implementation with incorrect target (50ms) interval (5ms) works well.
-
@KOM:
I never liked the One-Size-Fits-All GUI for traffic shaping. It causes confusion. The GUI should adapt to the shaping scheme being used.
Are you referring to the traffic-shaping wizard?
-
If the FairQ scheduler works well, a dead simple wizard that you enter in your up/down bandwidth, and it configures your interfaces and enabled FairQ. Some how people don't understand checking a box, selecting a drop down, and setting your bandwidth and need their hands held a bit. Make this a simple "anti bufferbloat" wizard.
The default traffic shaping wizard makes way too many child queues. I think my current setup is probably a good place to start.
HFSC
qHigh 40% LS - ICMP, games, DNS, NTP, SSH, etc
qNormal 40% LS Web(80/443/8080), VPN, etc
qDefault 20% LS All unknown stuff
qACK 20% RT 0% LSI'm also thinking of an alias for qHigh that will include a list of IP addresses for Voice chat and game servers because many of these do not run on standard ports.
I also have a floating rule at the top that matches all TCP and sets their qACK, this way all TCP connections, no matter what, will at least have qACK set.
You could possibly create two sub-queues under qDefault, one for TCP and another for UDP and make them a 50/50 split. The reasoning for this is UDP traffic tends to be low bandwidth but latency sensitive and TCP traffic tends to consume all available bandwidth. By separating them, you should be able to isolate UDP from the jitter inducing damage of greedy TCP streams. The default queue would then be qTCP under qDefault.
Just some ideas to play with.
The only functional difference (that I found) between FAIRQ and HFSC is the processing power needed. Both are Fair Queueing algorithms, but FAIRQ (an implementation of a SFQ algorithm) uses a simpler method of separating the flows which occasionally causes the fairness to be imperfect (hash collisions).
Read the Stochastic Fair Queueing paper to see if it offers any other advantages over other Fair Queueing algorithms that I may have missed.
I think the wizard makes too many default queues as well. For the sake of simplicity, something like UDP, High Pri TCP, Low Pri TCP, and ACK (only for High Pri TCP) gets my vote. Though, it would be great to have a wizard that created enough rules to cover 99% of users, including NTP, DNS, torrents, etc, etc.
FairQ combines queuing and scheduling while HFSC does just scheduling. FairQ has the benefit of being crazy simple to setup, HFSC has the benefit of allowing you to shape your bandwidth. FairQ is your 80/20 rule for most home users trying to fight bufferbloat and it requires no firewall rules to configure to gain immediate benefit.
-
If the FairQ scheduler works well, a dead simple wizard that you enter in your up/down bandwidth, and it configures your interfaces and enabled FairQ. Some how people don't understand checking a box, selecting a drop down, and setting your bandwidth and need their hands held a bit. Make this a simple "anti bufferbloat" wizard.
The default traffic shaping wizard makes way too many child queues. I think my current setup is probably a good place to start.
HFSC
qHigh 40% LS - ICMP, games, DNS, NTP, SSH, etc
qNormal 40% LS Web(80/443/8080), VPN, etc
qDefault 20% LS All unknown stuff
qACK 20% RT 0% LSI'm also thinking of an alias for qHigh that will include a list of IP addresses for Voice chat and game servers because many of these do not run on standard ports.
I also have a floating rule at the top that matches all TCP and sets their qACK, this way all TCP connections, no matter what, will at least have qACK set.
You could possibly create two sub-queues under qDefault, one for TCP and another for UDP and make them a 50/50 split. The reasoning for this is UDP traffic tends to be low bandwidth but latency sensitive and TCP traffic tends to consume all available bandwidth. By separating them, you should be able to isolate UDP from the jitter inducing damage of greedy TCP streams. The default queue would then be qTCP under qDefault.
Just some ideas to play with.
The only functional difference (that I found) between FAIRQ and HFSC is the processing power needed. Both are Fair Queueing algorithms, but FAIRQ (an implementation of a SFQ algorithm) uses a simpler method of separating the flows which occasionally causes the fairness to be imperfect (hash collisions).
Read the Stochastic Fair Queueing paper to see if it offers any other advantages over other Fair Queueing algorithms that I may have missed.
I think the wizard makes too many default queues as well. For the sake of simplicity, something like UDP, High Pri TCP, Low Pri TCP, and ACK (only for High Pri TCP) gets my vote. Though, it would be great to have a wizard that created enough rules to cover 99% of users, including NTP, DNS, torrents, etc, etc.
FairQ combines queuing and scheduling while HFSC does just scheduling. FairQ has the benefit of being crazy simple to setup, HFSC has the benefit of allowing you to shape your bandwidth. FairQ is your 80/20 rule for most home users trying to fight bufferbloat and it requires no firewall rules to configure to gain immediate benefit.
No. You are wrong. Refer to my other post in your pseudo-fair whatever thread.
-
https://forum.pfsense.org/index.php?topic=63531.0
I assume something like the checkbox in m0n0wall would be the best option?
-
https://forum.pfsense.org/index.php?topic=63531.0
I assume something like the checkbox in m0n0wall would be the best option?
Yep. Currently is way more difficult than it needs to be.
-
https://forum.pfsense.org/index.php?topic=63531.0
I assume something like the checkbox in m0n0wall would be the best option?
Yeah. Or dropdown menu, if people can come up with similar dead simple scenarios.
Basically something that people can tick and it improves things for them and gets (at least roughly) the work done. The traffic shaping frankly is over the head and unusable for vast majority of (non-geek/non-nerd) users.
-
Are you referring to the traffic-shaping wizard?
Not limited to. Even the various queue views include fields that don't apply depending on the shaping scheme being used. In my opinion, the entire Traffic Shaping GUI & wizard needs to be re-engineered. Now it's clunky and confusing.
-
@KOM:
Are you referring to the traffic-shaping wizard?
Not limited to. Even the various queue views include fields that don't apply depending on the shaping scheme being used. In my opinion, the entire Traffic Shaping GUI & wizard needs to be re-engineered. Now it's clunky and confusing.
I do like that all queueing disciplines have virtually the same layout though. Maybe grey out the field rather than remove it?
The wizards helped me, but more like a guide-line because I think it makes the simple too tedious and the complex just becomes a huge list of rules and qyeues that are not quite what you expected.
Maybe the shaper should have a few clicks setup for newbs and maybe a CLI-like terminal or something that will make the complex multi-WAN setups much quicker.
-
I would love to see a checkbox which said,
"Bypass Shaper for Squid traffic"
I think after reading about 50 posts on trying to get the 2 to work together and only having it work once with transparent mode (version 1.2.3) back in the day after dropping to the cli and replacing some ipaddresses this is long past due. - The two working in concert really really helps low bandwidth connections.
Regards
nzcam
