|
Bugzilla – Full Text Bug Listing |
| Summary: | Negotiated block ACK agreement buffer size is not enforced during aggregation | ||
|---|---|---|---|
| Product: | ns-3 | Reporter: | Rediet <redieteab.orange> |
| Component: | wifi | Assignee: | sebastien.deronne |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | ns-bugs |
| Priority: | P3 | ||
| Version: | ns-3.27 | ||
| Hardware: | All | ||
| OS: | All | ||
| Attachments: |
Patch (wrt changset 13275)
Patch (wrt changset 13287) Example script |
||
We cannot have more than 64 MPDU in a A-MPDU because of the compressed BA bitmap, so I do not think your change is acceptable. Or do I misunderstand what you are willing to do? A reproducible test case would be welcome to see the issue you have. (In reply to sebastien.deronne from comment #1) > We cannot have more than 64 MPDU in a A-MPDU because of the compressed BA > bitmap, so I do not think your change is acceptable. Or do I misunderstand > what you are willing to do? A reproducible test case would be welcome to see > the issue you have. Hi Sébastien, I actually wanted to highlight the cases where the destination of the BA session replies that it can only support X MSDUs/A-MSDUs (with X being strictly below 64). The problem is that this negotiated buffer size limitation is not taken into account when building A-MPDUs; the originator assumes that the buffer size is equal to the compressed bitmap size. I don't think that low-end devices will all have 64 memory slots available for BA sessions... I don't currently have a test case at hand. But will try to provide one, knowing that it'll surely require adding a new max buffer size attribute somewhere so as to be able to set different limitations. Created attachment 3037 [details]
Patch (wrt changset 13287)
Here is the updated patch. In it you'll find the following changes:
- max BA buffer size attribute was added to BlockAckManager. It can be configured through the Config store using an object attribute in RegularWifiMac;
- a missing condition on BA agreement status was added (since the agreement has to be established in order to be able to use it, otherwise stated, it could potentially be pending);
- the currently used constraint on an agreement's buffer size (multiple of 16) is not in the standard (neither in section 7.3.1.14 of .11e, as stated in corresponding comment, nor in section 9.4.1.14 of .11-2016) and was thus removed;
- since only compressed BA bitmap is currently implemented in ns-3, max of 64 is enforced where needed;
- the buffer size limitation of the device was enforced where needed (the peer's limitation notified through the ADDBA Response and both the peer's and the device's enforced when building A-MPDUs).
Created attachment 3038 [details]
Example script
An example script showing how to configure the BA buffer size limitation and it's impact on performance.
I do confirm what Stefano said; it was indeed fixed when he had reworked all the BA mechanism. The mpdu aggregator checks if the mpdu being aggregated is in the current TX window, whose size equals the buffer size. |
Created attachment 3032 [details] Patch (wrt changset 13275) During the ADDBA Request/Response exchange the recipient's buffer size has been received by the originator and stored as a parameter of the agreement. This size is enforced at the receiver size by MacLow. However, MacLow at the transmitter doesn't enforce this size when building A-MPDUs. This is not critical in the ns-dev, since the currently set buffer sizes are hard coded to maximum value, but it becomes limiting when playing around with buffer sizes. The attached solves this problem.