Prioritize WiFi Calling Traffic and fq_codel
-
What is the best way to prioritize WiFi Calling traffic while using an FQ_CoDel limiter setup?
I am using the recommended fq_codel setup from the "Playing with fq_codel in 2.4" thread.
I have a setup with 30 - 80 WiFi clients. Currently using limiters and FQ_CoDel which seems to share the bandwidth very nicely. We have been having problems with WiFi Calling not being super reliable. We are in a cellular dead zone so people are relying on it.
I was able to improve WiFi calling reliability by changing the Firewall Optimization to Conservative and changing the outbound NAT mode to Automatic rule generation.
I would like to further optimize by making sure all the WiFi calling traffic has top priority.
I am pretty green when it comes to traffic shaping and was hoping someone has a setup that is working well in pfSense that can be shared.
Netgate 6100 MAX
-
All Wi-Fi calling does is IPsec mobile. Generally UDP/4500 for the traffic tunnels.
Changing to conservative will not affect anything unless the phones are not sending proper NAT-T keepalives to keep the UDP states active.
Setting outbound NAT to automatic will not help unless the manual NAT was incorrect in which case I wouldn't have expected it to work at all.
Since you cannot see the traffic in the tunnel (it's encrypted between the phone and the cell carrier) about all you can do is prioritize outbound UDP/4500.
If your WAN is not consistently flat-lined sending (at capacity), I doubt it will make much if any difference.
Maybe your Wi-Fi infrastructure is simply not up-to-snuff instead and the VoIP is what makes it noticeable?
Chattanooga, Tennessee, USA
A comprehensive network diagram is worth 10,000 words and 15 conference calls.
DO NOT set a source address/port in a port forward or firewall rule unless you KNOW you need it!
Do Not Chat For Help! NO_WAN_EGRESS(TM) -
@cwagz I shape my VOIP phones via PRIQ and it all just works. I originally tried goofing around with HFSC and FQ_Codel and all that nonsense but nothing ever seemed to work. I don't know if anybody has it working well, and there is no definitive guide. The forums are full of people trying to get it working. PRIQ just works because it's simple. VOIP subnet has priority over all else at all times, full stop, the end.
-
Yes. For something low-bandwidth like VoIP you can just use priq to be sure that, if there is queueing, it is sent first.
Limiters work by dropping traffic. VoIP does not like dropped traffic. You might consider simply excluding traffic from those clients to UDP/4500 from the limiters (a matching rule higher in the rule set that does not set limiters).
-
@cwagz - Before changing traffic shaping algorithms, I would first recommend trying to reduce the quantum parameter on fq-codel to something smaller than the default 1514. This should help in situations where traffic with smaller packets needs to be prioritized.
Hope this helps.
-
Thank you for all the suggestions. I am going to try setting the quantum to 300 and see if that helps.
-
@Derelict said in Prioritize WiFi Calling Traffic and fq_codel:
All Wi-Fi calling does is IPsec mobile. Generally UDP/4500 for the traffic tunnels.
Changing to conservative will not affect anything unless the phones are not sending proper NAT-T keepalives to keep the UDP states active.
Setting outbound NAT to automatic will not help unless the manual NAT was incorrect in which case I wouldn't have expected it to work at all.
Since you cannot see the traffic in the tunnel (it's encrypted between the phone and the cell carrier) about all you can do is prioritize outbound UDP/4500.
If your WAN is not consistently flat-lined sending (at capacity), I doubt it will make much if any difference.
Maybe your Wi-Fi infrastructure is simply not up-to-snuff instead and the VoIP is what makes it noticeable?
Thank you for the response. I don't think the outbound NAT change had any affect. Changing to conservative did seem to improve the consistency at which each phone will stay connected to WiFi calling throughout the day. Some of the problems seemed to be related to the phones dropping back to the terrible cellular connection instead of staying connected to their WiFi calling tunnel.
I cannot rule out intermittent WiFi infrastructure issues. I believe I have the access points in the right places and setup correctly for roaming but this could be part of the issue.
@tman222 said in Prioritize WiFi Calling Traffic and fq_codel:
@cwagz - Before changing traffic shaping algorithms, I would first recommend trying to reduce the quantum parameter on fq-codel to something smaller than the default 1514. This should help in situations where traffic with smaller packets needs to be prioritized.
Hope this helps.
I changed to a quantum of 300. Two of the people that had been complaining told me they noticed a significant improvement in call quality / stability. I made a couple long calls and thought they were improved as well. I am going to leave it like this and see if the improvement holds out.
-
@cwagz - Thanks for getting back to us and letting us know that lowering the quantum did help.
It may not be perfect solution, but it's an attempt to make things more fair, especially on a busy connection with lower bandwidth. If you don't mind me asking, do you have asymmetric upload and download speeds or a lower bandwidth connection? I recently started using WiFi calling as well and so far things are working fine using just the fq-codel defaults. In my case though, the bandwidth is pretty high (symmetric 1Gbit fiber) and network usage is on the low side (i.e. a home network), which does make a difference.
Thanks again.
-
@tman222 said in Prioritize WiFi Calling Traffic and fq_codel:
@cwagz - Thanks for getting back to us and letting us know that lowering the quantum did help.
It may not be perfect solution, but it's an attempt to make things more fair, especially on a busy connection with lower bandwidth. If you don't mind me asking, do you have asymmetric upload and download speeds or a lower bandwidth connection? I recently started using WiFi calling as well and so far things are working fine using just the fq-codel defaults. In my case though, the bandwidth is pretty high (symmetric 1Gbit fiber) and network usage is on the low side (i.e. a home network), which does make a difference.
Thanks again.
We have FiOS 150/150. There are between 30-80 cell phones / tablets on the network. Depending on the time of day many people are streaming video and such.
-
Status > Monitoring is your friend there.
