Bugzilla – Bug 602
WifiRemoteStation lacks information about the access class of outgoing packets
Last modified: 2010-02-26 02:39:47 UTC
see thread: http://mailman.isi.edu/pipermail/ns-developers/2009-May/005927.html
Created attachment 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 attachment 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?
Changeset 4329a1519b3e and merging ns-3-bug-602.