Priority for Skype, SIP Phone, Go to Meeting, Google Hangout, Lync
-
Hello all
I have some problem about traffic in my office, users always have problem with (Skype, SIP Phone, Go to Meeting, Google Hangout, Lync)
I want to priority for (Skype, SIP Phone, Go to Meeting, Google Hangout, Lync) i select to do this with traffic shaper in pfsense, I use traffic shaper is right way or wrong wayPlease comment if you have any idea
Thanks
-
Me too
Thank you.
-
QoS can only control the priority of data you are sending.
To prioritize downloads, things get more complicated. There is a few methods like limiting outgoing ACK packets, or rate limiting (restricting all other incoming streams to 60%of your real-world download speed, theoretically leaving 40% of your connection available for Skype, SIP Phone, etc).
Some more details on your situation would be useful. Don't forget to search the forum for answers. :)
I like the Postal Service analogy for QoS; you can control when and how many letters you send (upload), but you cannot control when or how many letters/responses you will receive (download).
-
While traffic shaping can only shape data being "sent", data leaving your LAN interface can also be shaped. While it may seem strange at first to shape traffic that has already arrived, if you delay or drop packets for data flows that are coming in "too fast", you can keep the sender(assuming a good actor) from sending too quickly.
You do have to be careful because latency increases the delay before the sender backs off. My example is I have a 100/100 connection. I can send up to 98Mb/s with no issues, but if I shape my LAN to 98Mb/s, the senders don't get notified in time and many times will surpass my 100Mb connection for a brief moment. There just isn't enough time between 98Mb/s and 100Mb/s.
Another difference between ingress and egress shaping is that in my case, I have a 1Gb link between my computer and my firewall, so the firewall can receive data quicker than it will send it. Ingress from the internet is only 100Mb, while my LAN is 1Gb, so the data feed is slower than my interface. It's an inversion. The difference is that on egress, I shape before the data is sent, but on ingress, I can only shape after the data is sent. With higher latency and more in flight data, I need a larger buffer of spare bandwidth to give time for the sender to get notified to back off before overloading the connection.
I put a buffer of a few Mb/s on my LAN side, so 95Mb/s. I still keep my connection symmetrical, not like I'm going to care about the difference of 98 vs 95 on my upload.
-
Also, incoming UDP packets cannot be rate-limited because UDP has no congestion control. Only TCP has congestion control which can be leveraged to control bandwidth. This is one reason why UDP flooding was/is a popular denial-of-service method.