[LARTC] QoS in wireless networks

[LARTC] QoS in wireless networks

[Francisco Javier Simo Reigadas]

Hello,

I'm trying to configure several wireless routers with QoS support. The 
idea is to implement differentiated services so that VoIP traffic gets 
the maximal priority, then video, control traffic, interactive data 
traffic and best-effort traffic.

I have seen that CBQ used to be chosen as qdisc for implementing 
bandwith share in DiffServ but now HTB is preferred because it is 
simpler and more understandable. However, I see a problem with HTB in 
wireless networks: sometimes the available bandwith fluctuates due to 
interferences, retransmissions, etc, and then I don't know if HTB fits 
well for that. ¿What is the real effect of sharing 5Mbps among traffic 
classes  with HTB if the real bandwith dropped to 1Mbps? ¿Is CBQ better 
for these cases where the bandwith to share is not stable?

Thanks in advance

Javier
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] QoS in wireless networks

[Ferenc Kubinszky]

Hello,

On Mon, 3 May 2004, Francisco Javier Simo Reigadas wrote:
>
> I'm trying to configure several wireless routers with QoS support. The
> idea is to implement differentiated services so that VoIP traffic gets
> the maximal priority, then video, control traffic, interactive data
> traffic and best-effort traffic.

Good luck ;}

>
> I have seen that CBQ used to be chosen as qdisc for implementing
> bandwith share in DiffServ but now HTB is preferred because it is
> simpler and more understandable. However, I see a problem with HTB in
> wireless networks: sometimes the available bandwith fluctuates due to
> interferences, retransmissions, etc, and then I don't know if HTB fits
> well for that. ¿What is the real effect of sharing 5Mbps among traffic
> classes  with HTB if the real bandwith dropped to 1Mbps? ¿Is CBQ better
> for these cases where the bandwith to share is not stable?

But seriously...

There are many problems with QoS on a wireless (802.11) networks.
QoS mechanisms impelented by HTB, CBQ etc. are designed for a dedicated
point-to-point link with full controll all the queues at the sender side.

Today IEEE 802.11 does not support QoS at the link layer. All packets are
equal in the air. Moreover access points have exactly the same chance
to access the channel as clients have. It provides a half-duplex link, so
packets for uplink and downlink direction have to contend.
Just like a HUB... A HUB where packets can be transmitted at lower
speed, packets may collide, a destination station may disappear.

It is impossible to provide hard QoS, only some statistical QoS.

First forget the "bad channel" (packet loss, lower rate trasmit etc) a
bit.

IEEE 802.11 provides a fair channel access for all the nodes including APs
and clients. (I do not know about PCF mode implemented)
It means if the channel is full (nodes have some backlogged packets) a
node has to wait N-1 packets before access the channel where N is the
number of backlogged nodes. Note it is true statistically and we do not
care the bad channel. So it the best that can happen ;}
Not so good, but there is still some chances...

If you do not overload the channel nodes will not have backlog. (in long
term, in short term there might some)

First you must be sure that VoIP traffic will use only a fraction of the
capacity. Usually it is true. After that you must keep best effort traffic
below the maximal capacity. It is not so easy, because uplink and downlink
shares the same medium, so the must be summed.
Like this:
 BE_BW = BE_BW_DL+BE_BW_UL <= WLAN_BW - RT_BW_UL - RT_BW_DL - GUARD_BW
where

 BE_BW_DL: downlink best effort rate. You can control it easily at the AP
(or the router before the AP)

 BE_BW_UL: uplink direction. You can control it in the clients, but who
tell them how much bandwidth can the use? With TCP you can use ingress
filter in the AP, it will work fine. You have no chance against UDP :(

 WLAN_BW: How much is it really? Max 6Mbit/s for a "11mbps" wlan, but
there are still some "bad channel" effect.

 RT_BW_UL, RT_BW_UL: It has to be measured. Or neglected if you can.

 GUARD_BW: The channel must not be overloaded. And we neglected the real
time traffic.


It is not so difficult to build as it looks like ;}

If it is possible to separate bandwidth for uplink and downlink direction
(eg. no web/ftp server in the clinets), you can alocate X mbit/s
for downlink and Y mbit/s for uplink and control the two direction. Note
that uplink trafic should be TCP to be able to control it through ingress
filters and rate policers.

If you want to build a more flexible network you may use IMQ device. I
haven't used it because the required kernel and TC patches. But if you
manage it you can sum uplink and downlink traffic. Somehow...


You mentioned there are streaming and real time video traffic in your
network. Are there any uplink UDP video? There should not be any, or you
have to build a complex bandwidth controller in each nodes.

Best regards,
Ferenc

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] QoS in wireless networks

[Francisco Javier Simo Reigadas]

>There are many problems with QoS on a wireless (802.11) networks.
>QoS mechanisms impelented by HTB, CBQ etc. are designed for a dedicated
>point-to-point link with full controll all the queues at the sender side.
>
>Today IEEE 802.11 does not support QoS at the link layer...
>
I know, I have written myself that sencence several times in other 
documents :-)
In my previous message I should have written "partial QoS support".

>It is impossible to provide hard QoS, only some statistical QoS.
>  
>
I aggree.

>IEEE 802.11 provides a fair channel access for all the nodes including APs
>and clients. (I do not know about PCF mode implemented)
>  
>
It seems that it was abandoned because it didn't work as expected, only 
private extensions like Karlnet's Turbocell can do that (polling from a 
central point) and I am not interested in private extensions.

>After that you must keep best effort traffic
>below the maximal capacity. It is not so easy, because uplink and downlink
>shares the same medium, so the must be summed.
>Like this:
> BE_BW = BE_BW_DL+BE_BW_UL <= WLAN_BW - RT_BW_UL - RT_BW_DL - GUARD_BW
>where
>
>
>  
>
I have implemented something already and it works in the laboratory, the 
problem is that we cannot know how much is WLAN_BW. At the lab we can 
have 6Mbps and then doing a good outdoor installation with long links, 
the same configuration drops to 1Mbps or less, and that can still change 
as the weather evolves. That is why I made the question in the list: I 
can say that I have 6Mbps in the laboratory and then I create a HTB with 
subclasses, I reserve 1Mbps for VoIP and 5Mbps for BE; fine, it works. 
But what is going to happen when the real troughput drops? That doesn't 
happen in wired LANs (it happened in old phone connections though) but 
is very common in wireless longhaul installations. Let's put those well 
configured routers in their outdoor possitions, separated 15miles one 
from the other. The same configuration will then give a throughput of 
1Mbps or less. How HTB is going to do? I VoIP going to get the whole 
link? is BE going to collapse the link? are they going to get 
proportional shares (170kbps/830kbps) ? And, as opposed to HTB, what 
would be the behaviour of CBQ in the same situation? That is my doubt.

>You mentioned there are streaming and real time video traffic in your
>network. Are there any uplink UDP video? There should not be any, or you
>have to build a complex bandwidth controller in each nodes.
>  
>
Yes, we will do videoconference, there will be UDP audio and video in 
both uplink and downlink.

Thanks Ferenc for your message

Javier

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] QoS in wireless networks

[Michael Renzmann]

Hi.

Francisco Javier Simo Reigadas wrote:
>> IEEE 802.11 provides a fair channel access for all the nodes including 
>> APs and clients. (I do not know about PCF mode implemented)
> It seems that it was abandoned because it didn't work as expected, 

It's not abandoned, but it's an optional feature that mostly none AP has 
implemented. And it's not a complete protocol afair, but only a 
framework that leaves much room for the actual implementation.

> only private extensions like Karlnet's Turbocell can do that (polling
 > from a central point)

While Karlnet's Turbocell implements central polling, it does not make 
use of PCF. Instead, the stations work in DCF, and all traffic is 
transmitted as broadcasts (thus getting rid of 802.11 ACKs which gives 
some additional bandwidth). Downside: they loose the ability to have 
automatic rate selection.

> and I am not interested in private extensions.

Maybe you'll also consider this as private extension, but you might be 
interested in some "DCF-based polling protocol" implementations running 
under Linux:
frottle: http://frottle.sourceforge.net/
WiCCP: http://patraswireless.net/software.html
pewit: http://savannah.nongnu.org/projects/pewit

While they all perform a similar goal (implementation of a polling 
protocol on top of a normal ethernet link) they use different techniques 
to achieve their goal. But they all are not depending on a special 
device driver, so you can still choose your hardware freely.


And maybe also this link is of interest:
http://wsched.sourceforge.net/

"While the H-FSC qdisc can be used in a usual wireline environment (e.g. 
replacing the standard CBQ scheduler), the purpose of the port to Linux 
was to use it as a basis for the prototype implementation of a new form 
of wireless link-sharing. The basic problem is that in a wireless 
environment the amount of resources consumed in order to transmit X 
bytes to a mobile destination depends on the quality of the link to this 
station. The link-sharing model developed during the project allows the 
integration of goodput and resource-consumption oriented criteria in 
hierarchies for wireless link-sharing. Furthermore, the model can be 
used with currently available hardware because it can be implemented 
above the link layer. For detailed information take a look at the 
documents listed in the Documentation section."

They have two interesting papers about their work online:
"Packet scheduling for bandwidth sharing and quality of service support 
in wireless local area networks" and "A resource-based approach to MAC 
layer independent hierarchical link-sharing in wireless local area 
networks", explaining the ideas behind their scheduler.

Bye, Mike
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/

Re: [LARTC] QoS in wireless networks

[Michael Renzmann]

Hi.

Francisco Javier Simo Reigadas wrote:
> I'm trying to configure several wireless routers with QoS support. [...]

Do you mind telling something about the results? I'm really curious what 
happened since your first request...

Bye, Mike
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/