Bug 717 - Wrong slrc calculation at WifiRemoteStationManager when QoS is working
Wrong slrc calculation at WifiRemoteStationManager when QoS is working
Status: RESOLVED DUPLICATE of bug 602
Product: ns-3
Classification: Unclassified
Component: wifi
ns-3-dev
All All
: P3 critical
Assigned To: ns-bugs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-10-13 09:05 EDT by Kirill Andreev
Modified: 2009-10-22 09:57 EDT (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kirill Andreev 2009-10-13 09:05:49 EDT
Suppose the following situation: 

We have two stations A and B and we have two queues at each stations and packets to be sent in both queues at station A (all the packets are addressed to the station B). The second queue (with lower priority) has started to transmit a packet, but this packet has crashed (due to PER for example). After it DcaTxop will be notifyed about transmission failure and m_slrc in WifiRemoteStation shall be incremented. After this event, the first queue (with higher priority) has accessed the medium and started to transmit its frame. After successfull transmission m_slrc counter shall be set to 0, and previously crashed frame shall be transmitted with wrong slrc counter. Now suppose that station A and B can not communicate -- so, the packets from AC_BE queue shall be retried too many times when packets from AC_VO shall be dropped due to retry counter.

Proposed solution - is to add a map of <AccessCategory, retryCounter> rather than keeping retry counter only in WifiRemoteStationManager (but I do not know how will work rate control algorithms), like described in 9.9.1.6 of 802.11-2007, - short and long retry counters shall be supported for each AC
Comment 1 Kirill Andreev 2009-10-22 09:57:19 EDT

*** This bug has been marked as a duplicate of bug 602 ***