Use Traffic Shaping for Wi-Fi calling with cellular phones?
-
Hi,
I note that pfSense supports Quality of Service for VOIP applications, which is great. But we've eliminated POTS lines and are using cellular phones instead. The cellular phones use wi-fi calling to work well, even with poor cellular coverage. And I'd like to shape that traffic as well.
At least on Verizon (I'm not sure if this is a standard or not), the iPhone routes wi-fi calls using UDP ports 500 and 4500 (both UDP ports). I can't see a way to prioritize these packets using the traffic shaping wizard, or even adding a rule after the fact to shape this traffic.
Is there a way to use traffic shaping for wi-fi calling on cellular telephones? Thanks!
/Jeff
-
Sounds like they just tunnel IPsec. Just like those Microcell boosters. Prioritize that and you should be set.
You would need to find out if they always use UDP/4500 or if they use ESP (if there is no NAT involved) and be sure ESP is prioritized too.
-
I've tried the traffic shaper setting IPsec to run at a higher priority. I've tried both PRIQ and CBQ.
Much to my surprise (even with PRIQ), there was a bandwidth penalty even on an otherwise idle WAN circuit (about 20% performance hit).
I'd like to see equal bandwidth consumption assuming no traffic needs to be prioritized. Without traffic shaping, I was reliably seeing download speed tests of around 60 Mbps/second. With traffic shaping, I saw that drop to just shy of 50 Mbps/second (around 48-49).
My hardware is pretty powerful, I think (relatively speaking): I'm running hardware essentially identical to the XG-2758 1U.
Is this expected behavior? Is there anything I can do to have maximum throughput even with traffic shaping going on?
Thanks for the help, folks!
/Jeff
-
altq will certainly reduce the overall throughput of an interface but you should not be seeing a reduction down at those speeds.
You will probably need to post the shaper config.
Since it is so many screens you might just want to start by pasting the altq sections from the /tmp/rules.debug file.
You can just cat /tmp/rules.debug in Diagnostics > Command Prompt or edit the file in Diagnostics > Edit File.
-
Okay, I've looked at this again. Interestingly, while my circuit speed is "rated" at 50 Mbps, I found that I was getting more than that. I raised the limits in the wizard to 60 Mbps, and that seemed to help. But my upload speed used to be 58-59 Mbps, but with traffic shaping, it's down to 52 Mbps. That's a 10% hit.
What sort of hit should I expect here? I was under the impression that PRIQ shaping would not affect circuit speed at all, but may not guarantee minimum bandwidth for services if there's a lot of demand. I could live with that, but that's not what I'm seeing. Are my expectations unrealistic?
Below is the shaper config (the altq sections of /tmp/rules.debug):
set loginterface igb1 set skip on pfsync0 scrub on $WAN all fragment reassemble scrub on $LAN all fragment reassemble altq on igb0 priq bandwidth 60Mb queue { qACK, qDefault, qP2P, qOthersHigh, qOthersLow } queue qACK on igb0 priority 6 priq ( ecn ) queue qDefault on igb0 priority 3 priq ( ecn , default ) queue qP2P on igb0 priority 1 priq ( ecn ) queue qOthersHigh on igb0 priority 4 priq ( ecn ) queue qOthersLow on igb0 priority 2 priq ( ecn ) altq on igb1 priq bandwidth 62914.56Kb queue { qLink, qACK, qP2P, qOthersHigh, qOthersLow } queue qLink on igb1 priority 2 qlimit 500 priq ( ecn , default ) queue qACK on igb1 priority 6 priq ( ecn ) queue qP2P on igb1 priority 1 priq ( ecn ) queue qOthersHigh on igb1 priority 4 priq ( ecn ) queue qOthersLow on igb1 priority 3 priq ( ecn ) no nat proto carp no rdr proto carp nat-anchor "natearly/*" nat-anchor "natrules/*"
