Bug 2522

Summary: 802.11 broadcast adds delay between packets
Product: ns-3 Reporter: Richard <epachamo>
Component: wifiAssignee: sebastien.deronne
Status: RESOLVED INVALID    
Severity: normal CC: ns-bugs
Priority: P5    
Version: ns-3.25   
Hardware: PC   
OS: Linux   
Attachments: simple program to demonstrate bug. Source and a sink with tracing.

Description Richard 2016-10-14 21:04:23 UTC
Created attachment 2617 [details]
simple program to demonstrate bug.  Source and a sink with tracing.

It appears that a delay is added between packets when broadcasting in 802.11n and 802.11ac.

The following file iterates through 0-7 MCS's and both Guard Intervals.  There is a source and a sink, the source transmits rapidly and the sink receives.

When running the following file and analyzing the trace output, it seems there is a delay added in broadcast mode between packets.  It is small, but non-negligible.

I have tested this using sockets with similar results.  I have tested this in adhoc and infrastructure modes with similar results.

To switch between broadcast and non-broadcast in the attached file, toggle lines 121 and 122.
Comment 1 sebastien.deronne 2016-10-15 11:02:14 UTC
How much is the extra delay?
Did you analyze pcap traces which should clearly show why you have an additional delay I guess?

Also, why do you suspect this to be a wifi bug? This is triggered by a change at UDP level... Did you also try with other supports than Wi-Fi?
Comment 2 Richard 2016-10-15 16:08:55 UTC
The pcap files show that the packets are not even transmitted, so they don't show up on the pcap files.  pcap files show little difference in length of each packet or preambles.

That is a good point that it is triggered by a change at the UDP level. I assumed it to be at the wifi level because the phy layer explicitly deals with timing and the UDP does not.  When looking at the pcap files, the two UDP packets do not vary significantly.

The delay is about 1/10th of a millisecond.
Comment 3 sebastien.deronne 2016-10-18 16:31:46 UTC
Issue is obvious when looking at traces: without broadcast you have A-MPDU enabled, with broadcast you don't. A-MPDU can never be enabled when it is a broadcasted frame!
=> Bug rejected