Backpressure mechanism?

[saikat]

Hi,

Today I noticed a unique problem with cisco aironet 350 cards. I want to transmit unicast (UDP) packets to another laptop at a constant rate (say 30 packets per second), but the destination laptop may not be in range. What I noticed is that when the destination is not in range, so that the sender is not getting ACK packets back (I am not using RTS-CTS), the sender is sending only 2 packets per second instead of sending 30 packets per second !!!! This cannot be due to the specified backoff in 802.11 standard. Specifically, I had set the LongRetryLimit and ShortRetryLimit to 1. Moreover, I am using static ARP entries, so this cannot arise from that side as well. If I use a broadcast IP, then it is sending all 30 packets without any complaint, but not unicast packets. I used Linux and Windows both to test this out. Also, in Linux I used two versions of the driver (2.0 and 0.3). All are giving the same results. The only reason I could think of regarding this behaviour is that the card is overriding 802.11 backoff rules and stoping transmissions whenever it is not receiving a large number of ACK packets back. Can someone throw some light on this?

Thanks.

Saikat

[smalkeric]

First of all,

Does the UDP protocol support acknowledgements.? I think it does not. There are no acknowledgement for UDP packets.

And secondly,instead of 30 packets per second the source is sending 2 packets. This might be due to dropping of the packets due to fragmentation and other issues.

[saikat]

The ACK packets I am talking about is 802.11 ACK packets, it has nothing to do with UDP. To confirm the issue, I completely bypassed standard TCP/IP stack and sent raw packets (using PF_PACKET socket) to the interface, and observed the same problem. There was no fragmentations at any level. The mtu of the interface was set tp 2300 bytes (using ifconfig). Moreover, the fragmentation threshold of 802.11 card was set to 2312 to avoid MAC level fragmentations.

However, I did some more research and I think I understand what is the problem. The LongRetryLimit and ShortRetryLimit was set to 1 (to get a nice traffic pattern). The aironet card is however using its own *intelligence*. Whenever it does not get ACK (MAC level) packets from a destination, it ASSUMES that the node is down (or the network is down, I am not sure which one), and stops sending any more packets (at least) to that node until it sends or receives another beacon. Clearly, this is a carry-over from wired ethernet design and this is a VERY BAD assumption in wireless case, especially in adhoc networks where all the nodes are not in range of each other. The decision of not sending packets should be left to the routing protocol, and not on the MAC. Orinoco cards does not use this assumption, and as a result, numerous sources (mainly research papers) have noticed that orinoco works much better than aironet.

In fact there could be few more instances of the built-in *intelligences* of aironet card: I am observing that even if I set RTSThreshold to 2312, it stills sends some RTS packets whenever a large number of retries are required. In the driver, I can see that there is a way to tell the card not to use any retry for a given packet; I am yet to test this feature. In a similar way, is there any way to tell the card NOT TO override the RTSThreshold? At the driver level I should be given the complete control of what the card is doing. Is there a clause in 802.11 protocol about what to do if a packet reaches max retry (other than dropping that packet) and whether it is prohibited to send RTS for packets whose length is shorter than RTSThreshold?