Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Auto QOS fragmentation for VoIP over WAN - FreeBSD PFsense vs Cisco -

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    16 Posts 8 Posters 16.0k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • W
      wonslung
      last edited by

      i hate to be a newb here but couldn't you just lower the mtu of the entire interface and accomplish basicly the same thing

      1 Reply Last reply Reply Quote 0
      • E
        eri--
        last edited by

        There is the possibility to even this by inforceing the mss for TCP although not from the GUI yet.
        And its not that its undoable but i guess on point to point link mtu is negotiable so you can play with that otherwise i do not see anything special in that cisco thing that cannot be done with FreeBSD hence pfSense.

        1 Reply Last reply Reply Quote 0
        • O
          olivier1010
          last edited by

          Reducing statically the interface MTU does work, i tried it. But is not ideal. It means that there is a full time performance reduction for data.

          Same problem reducing the mss, as it does have a performance impact on TCP traffic for no reason when there is no VoIP traffic.
          More, it does work only to fragment TCp traffic, not UDP.

          If the MTU is dynamically changeable, it is better. We can then fragment only when necessary, but again, all the traffic is fragmented. I would say that it would be better to fragment selectively data trafic for the case where IAX is used in trunk mode. (the best would be to put a flag on VoIP trafic to leave it unfragmented)

          But you are right, what Cisco does is not really complex, it just makes it happen. In fact it is a bit more complex and efficient with ATM, because i think that in the case of IP over ATM AAL5 adaptation, Cisco is able to do the LFI stuff (fragmentation and interleaving) at the ATM level, where the 53 bytes cellule size of ATM is very efficient for this job. For this reason, we'll never have the ATM QOS efficiency for slow bandwith IP wan link.

          I think that those questions are important for the futur of the VoIP world, as many customers do not have the possibility to rent high bandwith SDSL, Cable or Fiber link, for private consumers as well as small companies.

          I will say that in our country (France) WAN quality is the biggest problem we have for full IP telephony. We can't yet propose the same level of reliability and quality than traditionnal telephony links, not because of technical limitations, but because the market (specially in France) is dominated and closed by a couple of big telcom providers.

          Having a better QOS for WANs, better that we can have today on Linux boxes, could help to change things.

          1 Reply Last reply Reply Quote 0
          • E
            eri--
            last edited by

            If you think that will make you better finance it.
            Otherwise it is not on my own priority list. It is quite doable in the same way AutoQoS of cisco does.

            In my plans is adding the WFQ for HFSC meaning being able to have a queue for each call but that is all in my plans regarding to this.

            1 Reply Last reply Reply Quote 0
            • G
              gnhb
              last edited by

              Ermal,

              How much money needs to be raised to get this project high on your priority list?

              Thanks,

              GNB

              1 Reply Last reply Reply Quote 0
              • E
                eri--
                last edited by

                Well minium 1.5K

                1 Reply Last reply Reply Quote 0
                • E
                  eri--
                  last edited by

                  For reference http://www.cs.virginia.edu/~mngroup/projects/qosbox/snooplet.html should do all that Cisco does.

                  1 Reply Last reply Reply Quote 0
                  • C
                    cmb
                    last edited by

                    What Cisco does is LFI, Link Fragmentation and Interleaving. AutoQoS in Cisco IOS enables it if the link speed is 768 Kbps or slower. In practice, it doesn't do much unless your link speed is 256 Kbps or slower, anything faster and the serialization delay isn't enough to make a considerable difference. Serialization delay on a 1500 byte frame at 256 Kbps is about 47 ms, so at 256 Kbps you're adding potentially as much as 47 ms of jitter (worst case scenario) to a VoIP frame that comes in immediately after a 1500 byte frame is sent. Even that generally wouldn't be enough to cause much or any quality degradation. At 128 Kbps or slower, it's a considerable benefit.

                    In some parts of the world, this would still have some benefit today on their low speed links. In most of the world, it's irrelevant, as link speeds have become faster than the levels where this has a worthwhile impact.

                    1 Reply Last reply Reply Quote 0
                    • R
                      rviteri
                      last edited by

                      Is there still an interest of this feature becoming a bounty?

                      1 Reply Last reply Reply Quote 0
                      • S
                        seank
                        last edited by

                        I have some customers that intermittently complain about voice quality.  I'm going to order a Cisco router that can do "AutoQOS" and see if it makes a difference.

                        1 Reply Last reply Reply Quote 0
                        • J
                          jits
                          last edited by

                          This is a great discussion and a valid one at that. I'm no expert, but wouldn't this be better implemented as a function of the network adapter and at the switch level? Layer 1 function?

                          Why burden the firewall software anymore?

                          1 Reply Last reply Reply Quote 0
                          • First post
                            Last post
                          Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.