Bug 2326

Summary: False duplicate frame detection using EDCA QoS data frames
Product: ns-3 Reporter: CHep <hepner>
Component: meshAssignee: Tom Henderson <tomh>
Status: NEEDINFO ---    
Severity: normal CC: ns-bugs, sebastien.deronne, tomh
Priority: P5    
Version: ns-3.25   
Hardware: All   
OS: All   

Description CHep 2016-03-05 06:53:01 EST
Since the changes reported in Bug 1901 (accepted for ns-3.24) i have recognized a significant performance degradation in my wireless mesh simulations. This degradation is caused by the detection of false duplicates in MacRxMiddle. My assumptions are described in the text below.

In (1901) Data packet format was changed from plain Data to QoS Data according to the standard.
This also affects the calculation of sequence numbers in "mac-tx-middle".
Sequence numbers are calculated for every Receiving Station (RA) and TID (Traffic ID). (This is also described in IEEE802.11-2012 9.3.2.10 Duplicate detection and recovery "A STA operating as a QoS STA shall maintain one modulo-4096 counter, per <Address 1, TID>, for individually addressed QoS Data frames"); ("A non-QoS STA shall assign sequence numbers to management frames and data frames from a single modulo-4096 counter, starting at 0 and incrementing by 1, for each MSDU or MMPDU").

In MacRxMiddle::Receive duplicates are filtered out.
In the function IsDuplicate a duplicate is detected if the packet is a retry packet and the sequence control is equal to the last saved sequence control.
(IEEE802.11-2012 9.3.2.10 "The receiving QoS STA shall also keep a cache of recently received <Address 2, TID, sequence-number, fragment-number> tuples from QoS Data frames from all STAs from which it has received QoS data frames.")
However the following scenario leads to a false discarding of a duplicate.

Assume 3 Stations in a chain. STA1 - STA2 - STA3
1. STA2 is sending a packet to STA3 with Seq.Nr. 5
2. This packet is received by STA1 and STA3!
3. STA2 is now sending a packet to STA1 (also) with Seq.Nr. 5
(assuming two concurrent streams it can likely happen that these Seq.Nr. are the same).
4. Due to interference STA1 couldn't Receive the packet send by STA2.
5. STA2 retransmit the packet to STA1 with Seq.Nr. 5
6. STA1 is receiving the retransmitted packet with Seq.Nr. 5
7. STA1 is discarding the packet because of a false detection of a duplicate.

The reason is the previously received packet from STA2 with Source Address STA3 and same Seq.Nr. 
This Seq.Nr. is stored as the last Seq.Nr. from STA2.  

This seems very unlikely to happen in real Hardware. My assumption is that packets not addressed to the receiving STA should be discarded before the detection of duplicates and also not saved as their last Seq.Nr.
Comment 1 sebastien.deronne 2016-03-05 10:17:23 EST
Could you attach your scenario?
Thanks!
Comment 2 sebastien.deronne 2016-03-11 17:33:21 EST
It looks like a mesh-related problem, as the referenced bug points to the mesh module.
Can this bug be moved to the mesh module? This has more chance to be fixed if it is correctly assigned.
Comment 3 CHep 2016-03-14 05:53:00 EDT
The Bug occured in a Mesh Scenario that's right,
however I don't think that it is just related to MESH
as the Bug is in MacRxMiddle.

I have not tested it but what would happen, if  STA2 would be an AP and STA1 and STA3 the associated Clients? The Bug should occur as well.

The Bug occurs in MacRxMiddle::IsDuplicate
which is called in  MacRxMiddle::Receive

However the Problem is in MacRxMiddle::Receive
  if (!hdr->GetAddr1 ().IsGroup ())  
    {originator->SetSequenceControl (hdr->GetSequenceControl ());
In this part only Group adresses are neglected and the last sequence number is saved. There is a check needed if the currently received packet belongs to the receiving station.
Comment 4 sebastien.deronne 2017-01-20 02:50:35 EST
I just see this back in our basket.
I unfortunately miss time to investigate mesh related issues, so I really think mesh people should have a look first and if it is confirmed to be pointing to wifi then I can have a look.
Comment 5 sebastien.deronne 2017-01-23 15:24:38 EST
Once again, it seems at first sight a mesh-related problem:
- issue is seen since changes done in the mesh module;
- reproduction case concerns a mesh scenario.

If you want wifi people to investigate this, you should come with a better understanding about why this is for sure a bug in the wifi module.

Moving back to mesh in the meantime...
Comment 6 Tom Henderson 2017-01-23 15:38:33 EST
(In reply to sebastien.deronne from comment #5)
> Once again, it seems at first sight a mesh-related problem:
> - issue is seen since changes done in the mesh module;
> - reproduction case concerns a mesh scenario.
> 
> If you want wifi people to investigate this, you should come with a better
> understanding about why this is for sure a bug in the wifi module.
> 
> Moving back to mesh in the meantime...

I will take this and look further into it.. it is not really in the mesh code but triggered by mesh use case, but anyway, we shall see.
Comment 7 sebastien.deronne 2017-01-23 15:42:22 EST
(In reply to Tom Henderson from comment #6)
> (In reply to sebastien.deronne from comment #5)
> > Once again, it seems at first sight a mesh-related problem:
> > - issue is seen since changes done in the mesh module;
> > - reproduction case concerns a mesh scenario.
> > 
> > If you want wifi people to investigate this, you should come with a better
> > understanding about why this is for sure a bug in the wifi module.
> > 
> > Moving back to mesh in the meantime...
> 
> I will take this and look further into it.. it is not really in the mesh
> code but triggered by mesh use case, but anyway, we shall see.

Thanks Tom.
I am ok to take over investigation if you confirm this is a wifi bug.