Created an attachment (id=585) [details]
Add retry counters for QoS stations.

This patch should resolv problem of shared counters for QoS and Non-QoS
packets.
Interested classes are:

ns3::WifiRemoteStation
ns3::DcaTxop
ns3::EdcaTxopN
ns3::MacLow

When a packet (data or cts) is correctly/incorrectly received is called
relative method in WifiRemoteStation with indication of the access class which
packet belongs in order to update correct retry counter.

Created an attachment (id=639) [details]
Patch v2

This patch adds also TracedSources for new counters.

*** Bug 717 has been marked as a duplicate of this bug. ***

Have I understood correctly, that the only thing, that prevents this bug from
being fixed, is rate control, which may start to work incorrectly? Is it
possible to move retry counters from WifiRemoteStationManager to DcaTxop (as
soon as it is responsible for packet retransmission and fragmentation), and
change interface to rate control as follows: when a packet has been transmitted
or failed, we give AC, retry counter, and packet itself to the rate control? I
think, that it is closer to real-life situation (specially, some real rate
control algorithms use such interface), but a huge amount of code must be
changed. Another approach is not to touch rate-control dependent part of
WifiRemoteStationManager and move retry counters to DcaTxop only (because I
have not found any contraries with a standard).

When I was writing a patch, which fixes airtime link metric
(see proposed fix of this bug here:
http://code.nsnam.org/mathieu/ns-3-bug602/), I have observed, that rate control
does not wokr any more.
Are there any news about fixing this?