Reply To: QOS and VoIP

Home Page Forums Network Management ZeroShell QOS and VoIP Reply To: QOS and VoIP

#46254

olivier1010
Member

It can be a problem for very small business where the DSL link is shared between Data and VoIP.

In our country there are lots of very small business companies.

It is not possible here to have multi play offers (multiple ATM VCI channels). Tier 1 providers keep this technology too expensive, they are using it but only for their residential offers (triple play : data, TV and Voice).

As the global DSL infrastructure in the country is managed by only two tier1 providers (France Telecom and SFR), there is no possibility to solve the problem.

So we are using at small clients sites a normal ADSL link.

As we can’t have neither ADSL annex M in France, because it is forbidden by the telcom regulation authority (ARCEP), the maximum upload speed we can have is about 800 to 900 kbps in best cases with ADSL2+.

When we have this speed, there is no real problem, QOS is working good enough for VoIP.

But in the field, we can have upload speeds from 256 to 600 kbps or sometimes less when reach extended ADSL is used for very long lines.

In this case, a 1500 bytes packet cause a delay that can be bigger than some VoIP providers buffers using old hardware designed for fiber links where small buffers are enough.

Reducing the MTU to about 500 bytes is not a solution, because some web sites and applications do not tolerate this, for example if you do this, the Maxtrox.com web site will stop to work.

One of the main benefit of using QOS is costs reductions.

To allow QOS to work on slow links for realtime traffic like VoIP, there is no other solution than reducing the data MTU, or better, fragmenting the data traffic between edge routers.

This could be done through a specific router interface. An example of such a special router interface is the one we can have on Mikrotik routers, where we can use a “packer” interface, to compress IP headers between two routers.

This concept could be extended to an autofragmenting interface, managed by the linux kernel, or eventualy inside a user land process if M Torwald do not want this inside the kernel. Using such an interface between two routers would allow to reduce the Data MTU size transparently, only when needed.