Auto QOS fragmentation for VoIP over WAN - FreeBSD PFsense vs Cisco -
-
Ermal, even if we can dequeue dynamically packets with the new AltQ, reducing the time needed to trasmitt a VoIP paquet in
presence of 1500 bytes Data paquets to a minimum of say one or two 1500 bytes paquets, it will not be possible to do more with
AltQ.
Again, on a slow WAN, a VoIP paquet must wait as long as say 20 - 150 ms, as soon as there is only one remaining queued 1500
bytes Data paquet to transmitt.
This is a big amount of jitter, specialy when the Data trafic is no fully uniform. Imagine now the amount of jitter, if the
sheduler allow for 2 or 3 Data paquets to go out before a VoIP paquet. This will translate to 60 - 450 ms. Unacceptable.
So the problem does not come from the sheduler, but really from the lenght of the Data paquets.
There are no other solutions, mathematicaly speaking, than reduce the Data frame lenght to reduce VoIP Jitter.
(In fact there is another one : stop Data trafic completly during VoIP calls :=) this is what we are doing when we have very
important calls on the trunk !). Very effective solution :=)
Seriously :
To reduce this Data frame lenght, the OS system needs to be able to fragment dynamically Data trafic, when VoIP trafic need to
be transmitted with a high priority low jitter class.
Is FreeBSD able of doing this ? I do not think so, and Linux neitheir.
I think that the same problem does exhibit for games, with an eratic and or higher latency when the Data trafic load is heavy
on a slow wan link.
Take a Cisco router, activate VoIP autoqos on it, overload its 250 kbps WAN uplink with http traffic at 100 % (250 kbps), use
iperf to generate UDP trafic classified in the VoIP queue and measure UDP jitter in the same uplink direction.
You will see that it stay under acceptable levels (< 50 ms).
Do the same thing with Linux or BSD and the best QOS rules and sheduler. You will see that the jitter will go over 100ms,
possibly over 200 - 300 ms or worse.
Cisco not only dequeue data paquets to give room to VoIP paquets, but reduce as well Data paquet size (fragmenting them) to
allow for a smaller jitter and lower latency.
Without fragmentation, even with very high priority for VoIP paquets, the best that a sheduler can do is put one VoIP paquet
after one Data paquet. Not more
Unfortunately this in not enough on slow wan links, for two reasons :
- The changes in each data paquet size produce jitter on VoIP trafic :
see this example :
small lines are voip paquets
longer ones are Data paquets of different sizes–- ------------------------- --- -------- --- ------------------------------------------- --- ---------------- ---
you can clearly see that the time between VoIP paquets greatly varry.
- to allow for a greater load sharing efficiency between different trafics, the "one voip paquet for one data paquet" rule is not usable for sheduling. it does work for a simple trafic scheme, but as soon as there is more than one call, mixed trafic bandwith, or parallel trafic with high priority like tcp ack, it does not work.
So the conclusion is that there is no other way than fragmenting the Data trafic in presence of VoIP trafic on slow Wans to get good quality VoIP.
Cisco did it like this and i think this is the only way. They call it "link efficiency mechanisms such as link fragmentation and interleaving (LFI) and low latency queuing (LLQ)"
At the ATM level it is easy to do LFI without touching the IP MTU. But in the IP world reduncing the MTU means fragmenting the tcp/udp data trafic.
See this white paper :
http://www.cisco.com/en/US/tech/tk543/tk759/technologies_white_paper09186a00801348bc.shtml#wp39909
or pdf version :
http://www.cisco.com/warp/public/cc/pd/iosw/prodlit/autwp_wp.pdf
Sometime it can produce indesirable effects because a receiving router or server cannot deal with fragmented trafic, but this is still better than having micro cuts in the VoIP calls, most of the time giving a disastrous image to the company.
-
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
-
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. -
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.
-
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.
-
Ermal,
How much money needs to be raised to get this project high on your priority list?
Thanks,
GNB
-
Well minium 1.5K
-
For reference http://www.cs.virginia.edu/~mngroup/projects/qosbox/snooplet.html should do all that Cisco does.
-
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.
-
Is there still an interest of this feature becoming a bounty?
-
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.
-
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?