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@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
