1

I was working with a client-server project based on UDP and 802.11 as a link and physical layer. There, the client was trying to probe some packets in the wireless channel to gauge channel condition. This function is required to set up the transmission speed and estimate packet drop rate in my client application. To carry out that function, it is required to measure the number of re-transmissions (topology is client -----ap ------server: where ----- is a wireless channel) that are occurring in IEEE 802.11. In the transport layer, there won't be any re-transmission, as UDP is used, but if the wireless channel is bad (no acknowledgment from the receiver MAC), the IEEE802.11 Wi-Fi NIC will re-transmit. So far I could access the RSSI from ~/proc/net/wireless in linux, which gives an idea about the received signal strength but not about the wireless channel condition. Wireless channel condition could be estimated from the number of retransmission. How should I measure the number of re-transmission in IEEE 802.11 layer, Say for 1 packet from application how many re-transmission (from a client) in IEEE 802.11 layer?

Or Is there any way to stop the IEEE802.11 re-transmission feature?

  • Your host/server configuration and OS is off-topic here. Removed the question about kernel hacks. – Ron Maupin Oct 26 '18 at 19:20
  • This is something you may want to do on the WAP or WLC. An enterprise-grade WAP or WLC probably has such statistics. – Ron Maupin Oct 26 '18 at 20:17
  • Did any answer help you? If so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you can provide and accept your own answer. – Ron Maupin Dec 25 '18 at 9:47
2

It is required to measure the number of re-transmission that is occurring in IEEE 802.11.

You don't specify the direction of the UDP traffic. If it is largely from server to client, then a client won't be able to accurately measure this statistic. Only the AP would have a chance to capture this information.

Why? Because a client will ACK the first 802.11 frame it understands/receives so it won't know how many times the AP tried to send the frame previously. It wasn't able to understand/receive those previous attempts.

If it is from client to the server, you may be able to write/use a specialized driver that could give you these statistics, but that may depend on the hardware as well. Of course, the results will likely change whenever any environmental conditions change.

Say for 200 packets from application how many re-transmission in IEEE 802.11 layer?

There is no way to say without actually measuring this in some way, but some enterprise wireless systems can provide retranmission/retry statistics (at least from AP to client).

When an 802.11 frame is transmitted and no ACK is received, it is retransmitted a certain number of times. Once a threshold of retransmissions is reached, the data rate is adjusted downward to try again.

Now different vendors apply the standards in slightly different ways to try to optimize wireless traffic so their product out performs competitors. These optimizations are often only known to those inside the company. Some of the differences could be (don't take this as a full list):

  • How many retransmissions before a lower data rate is tried?
  • How is the next data rate selected when lowering the data rate?
    • The next lowest MCS value (802.11n/802.11ac)?
    • The next lowest SS value (802.11ac)?
    • The next lowest data rate irregardless of MCS/SS values?
    • Does it skip data rates/MCS/SS values on the way down?
    • Some combination of the above?
  • How many total retransmissions to allow before entirely dropping the frame?
  • Which data rate is the next frame started at?
    • Start from the highest client supported data rate (i.e. aggressively try for the best data rate all the time)?
    • Start from a value slightly above the last successful tranmission (i.e. conservatively increase the data rate for least retransmissions)?
    • Maintain statistics for each client and start somewhere on the upper portion of the bell curve (i.e. where 75-90% of the successfully delivered frames are below that data rate)?
    • Some other algorithm or process?
  • Do any of these shift based on other external factors (number of clients, noise levels, etc)?

Which brings us to the other environmental factors that would be specific to where you were trying to determine the answer to how many retransmissions. How much noise in the RF environment and does it fluctuate? How many other devices trying to communicate on the same channel? And so on.

Asking anyone to tell you how many retransmissions you will have is simply impossible. It needs to be measured.

Or Is there any way to stop the IEEE802.11 re-transmission feature?

Never seen one and I doubt you will. As I have elaborated above, the retransmission process is part of how frames get delivered at the best possible data rates. Some vendors allow a bit of "tweaking" to the specifics of how many retransmissions take place at different points in the process, but to eliminate them entirely would generally be a very bad idea.

The best you may be able to do is to reduce the number of retransmissions to a minimum threshold. For instance, find a vendor that does allow some "tweaking" to settings such as the number of retransmissions. Then configure a client to only support a small subset of data rates or a single fixed data rate (this will have to be the only base/basic/required supported by the WLAN as well). You would have to pick a slower data rate that would provide for reliable delivery of frames in all conditions.

  • in raspbian stretch and ubuntu 18.04.1 /sys/class/net/wlan0/statistics contains some interface-specific information. I was wondering if these statistics are before/after (sending/receiving) the link layer? – H.Jamil Oct 30 '18 at 3:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.