Which SNMP variables to diagnose/characterise wifi congestion?

The simple approach would be just monitoring the IF-MIB::ifInOctets.<ifIndex> / IF-MIB::ifOutOctets.<ifIndex> OIDs periodically and checking against the available bandwidth. From your linked MikroTik MIB you can discover the currently set rates by reading the mtxrWlStatTxRate: 1.3.6.1.4.1.14988.1.1.1.1.1.2.<ifIndex> and mtxrWlStatRxRate: 1.3.6.1.4.1.14988.1.1.1.1.1.3.<ifIndex>. This of course would not take wireless specifics into account, but be able to give you a rough idea if the total available bandwidth on your interface is the bottleneck (it likely is if you see usages near the total channel capacity).

In general, unless your stations or antennae are located poorly and the ether is clean at the chosen channel's frequency, you can expect a throughput of roughly 2-3 MB/s from a single G-channel (54 MBps 2,4 GHz).

If you need more specific information on retries and errors from the AP side, you can read the dot11Counters table of the IEEE802dot11 MIB - specifically the dot11RetryCount, dot11MultipleRetryCount and dot11FailedCount values of the appropriate instance.

802.11 does not have any collisions but physical carrier sensing and optionally an RTS/CTS handshake prior to transmission of frames. Monitoring the dot11RTSFailureCount will give you a rough idea of how often an RTS request is not replied by a CTS, thus not granting the channel to the sending station.

Note that you may see a relatively low amount of retries and RTS failures if it is your access point generating the vast majority of the traffic (i.e. the stations are mainly receiving data). You might want to take a look at IF-MIB::ifOutDiscards.<ifIndex> at the wireless interface or IF-MIB::ifInDiscards.<ifIndex> at the wired interface as well as these numbers would increment whenever the buffer is full and cannot receive any additional frames (i.e. the AP is sending at full rate but frames at the Ethernet interface keep arriving at a faster rate).

If all you are trying to do is prove to the client that they are overloading the AP, you can use the dot11RetryCount and dot11MultipleRetryCount OID's.

dot11RetryCount - 1.2.840.10036.2.2.1.4

dot11MultipleRetryCount - 1.2.840.10036.2.2.1.5

This will give you a rough estimate of how congested the air is. Once the Retry count reaches more than about 10% of the dot11TransmittedFrameCount, you will start to see slowdowns.

Here's Cisco's MIB object walker - that should help if you need to figure out other OID's to examine.

http://tools.cisco.com/Support/SNMP/do/BrowseOID.do?local=en&translate=Translate&objectInput=1.2.840.10036.2.2.1.13#oidContent