Bugzilla – Bug 2116
refactoring aggregation API
Last modified: 2016-02-05 15:50:53 UTC
The API for aggregation at the helper level is more complicated than it ought to be. This is due to the fact that parameters are set per AC. I.e., for AC_BE, we currently set aggregation as follows: mac.SetBlockAckThresholdForAc (AC_BE, 2); mac.SetMpduAggregatorForAc (AC_BE,"ns3::MpduStandardAggregator", "MaxAmpduSize", UintegerValue (aMpduSize)); mac.SetMpduAggregatorForAc (AC_BE,"ns3::MpduStandardAggregator", "MaxAmpduSize", UintegerValue (aMsduSize); We would like these parameters be exposed as attributes such as: mac.SetTypeForAc (AC_BE, "MaxAmpduSize", UintegerValue (aMpduSize), "BlockAckThreshold", UintegerValue (2), "MaxAmsduSize", UintegerValue (aMpduSize));
Also, the helper should be improved to select good default settings. If anyone has knowledge about common default settings, feel free to share.
Created attachment 2180 [details] Proposal to refactor the aggregation API Here is the proposed changes to refactor the aggregation API. This makes it much easier for the user to set the A-MSDU and A-MPDU parameters. Note that those changes are expected to be applied on top of the patch for https://www.nsnam.org/bugzilla/0. Also, another improvement would be to select meaningful default values, certainly based on the 802.11 standard being configured. But it would require some information about common value used by most vendors. Does someone may get or have such information? Remark: I'll update the documentation once all changes are approved.
The current patch seems to have a lot of complexity; attributes are enumerated by access category; e.g. BE_MaxAmsduSize. In practice, is aggregation usually enabled for anything other than best effort? Are values for block ack configuration varied by access category? If not, I suggest the following. - one attribute for maximum A-MSDU length, default to 7935 - one attribute for maximum A-MPDU length, default to 65535 - one attribute for block ack threshold, default to 2 - one attribute for block ack inactivity timeout, default to 0 and then, by default, when 802.11n is configured, AC_BE is configured for aggregation and block ack, and the other ACs are not. i.e. users will not typically even see any configuration statements for aggregation in the example programs-- they just configure 802.11n and get AC_BE aggregation automatically. If we want to allow AMPDU configuration of other AC, then provide an advanced attribute that is a bitmapped integer with a bit for each AC for which a user wants to enable aggregation; e.g. the value 0 disables aggregation, the value 1 enables it for AC_BE only, the value 2 for AC_BK only, the value 3 will enable for both AC_BE and AC_BK, etc.
A-MPDU is by default enabled for BE on most 802.11n devices, but it is generally possible to enable it for other ACs. I agree with the bitmap solution. The only bad effect is that we do no longer allow the user to configure a different maximum A-MPDU size depending on the AC, while this was allowed in the previous API (even though this is generally not done in the field).
Is that acceptable that we do no longer allow the user to configure a different maximum A-MPDU size depending on the AC? If yes, then I'll adapt my patch.
I was able to find evidence that some drivers do permit A-MPDU setting on a per-AC basis. I couldn't find discussion of it in the standard (only the value of maximum A-MPDU size that applies across all access classes). The paper here: http://www.europment.org/library/2014/prague/bypaper/ECS-EET/ECS-EET-09.pdf states: Existing off-the-shelf schedulers for IEEE 802.11n (such as ath9k driver [5]) perform separated MPDU aggregation for individual access category (AC) of video, back gr ound and best effort (AC_VI, AC_BK, AC_BE), while they do not perform aggregation for Voice Access Category (AC_VO) (e.g., VoIP) and then it goes on to advocate for A-MPDU also for AC_VO. So it seems reasonable to me to expose these on a per-AC basis, so I don't have anymore a question about how you exposed them per-AC. I have some other questions about the patch: 1. we have a dependency between the overall max MPDU size set as an attribute in MpduStandardAggregator, and these per-AC values. It is possible to configure per-AC values that exceed the overall max MPDU size and not raise any error. Due to static initialization order issues, we cannot use the value of one attribute to cross-check the value of another at attribute construction time. The solution probably is, when the value is needed in the code, to fetch both the overall MaxAmpduSize() and the per-AC value, and use the min() of the two. What do you think? I don't see this kind of check presently in the setter methods. 2. why is RegularWifiMac holding these per-AC attributes? RegularWifiMac does not necessarily have 802.11n configured. Why not put them in MpduStandardAggregator? 3. Why is the default to disable block ack inactivity timeout (default value of 0)? The standard says: 10.5.4 Error recovery upon a peer failure Every STA shall maintain an inactivity timer for every negotiated Block Ack setup. 4. I would prefer a default profile (default values) that enables block ack thresholds and A-MPDU and A-MSDU values when 802.11n and ac are configured, based on some defaults found in the field (unfortunately, I could not find these values based on my searching yet this morning). I doubt that most Wi-Fi users will touch these values unless doing research of the sort that is cited above, and I'd prefer to keep this attribute out of the basic configuration for 802.11n. i.e. simply calling wifi.SetStandard (WIFI_PHY_STANDARD_80211n_5GHZ); should enable what is typically enabled in practice by default when 802.11n is deployed. I realize you had a comment about using the helper to select good defaults, but I'd rather see the defaults in the attribute configurations themselves.
(In reply to Tom Henderson from comment #6) > I was able to find evidence that some drivers do permit A-MPDU setting on a > per-AC basis. I couldn't find discussion of it in the standard (only the > value of maximum A-MPDU size that applies across all access classes). > > The paper here: > http://www.europment.org/library/2014/prague/bypaper/ECS-EET/ECS-EET-09.pdf > > states: > > Existing off-the-shelf schedulers for IEEE 802.11n (such as > ath9k driver [5]) perform separated MPDU aggregation for > individual access category (AC) of > video, back gr > ound and best > effort (AC_VI, AC_BK, AC_BE), while they do not perform > aggregation for Voice Access Category (AC_VO) (e.g., VoIP) > > and then it goes on to advocate for A-MPDU also for AC_VO. > > So it seems reasonable to me to expose these on a per-AC basis, so I don't > have anymore a question about how you exposed them per-AC. > > I have some other questions about the patch: > > 1. we have a dependency between the overall max MPDU size set as an > attribute in MpduStandardAggregator, and these per-AC values. It is > possible to configure per-AC values that exceed the overall max MPDU size > and not raise any error. Due to static initialization order issues, we > cannot use the value of one attribute to cross-check the value of another at > attribute construction time. > > The solution probably is, when the value is needed in the code, to fetch > both the overall MaxAmpduSize() and the per-AC value, and use the min() of > the two. What do you think? I don't see this kind of check presently in > the setter methods. That attribute in MpduStandardAggregator has been removed in the patch. > > 2. why is RegularWifiMac holding these per-AC attributes? RegularWifiMac > does not necessarily have 802.11n configured. Why not put them in > MpduStandardAggregator? I have put them there because it makes configuration easier, by configuring each STA or AP directly with the aggregation parameters. But there is indeed no check whether the maximum value does not violate any standard rule. > > 3. Why is the default to disable block ack inactivity timeout (default > value of 0)? The standard says: > > 10.5.4 Error recovery upon a peer failure > Every STA shall maintain an inactivity timer for every negotiated Block Ack > setup. I will have a look, I am not really familiar with that attribute. > > 4. I would prefer a default profile (default values) that enables block ack > thresholds and A-MPDU and A-MSDU values when 802.11n and ac are configured, > based on some defaults found in the field (unfortunately, I could not find > these values based on my searching yet this morning). I doubt that most > Wi-Fi users will touch these values unless doing research of the sort that > is cited above, and I'd prefer to keep this attribute out of the basic > configuration for 802.11n. i.e. simply calling wifi.SetStandard > (WIFI_PHY_STANDARD_80211n_5GHZ); should enable what is typically enabled in > practice by default when 802.11n is deployed. > > I realize you had a comment about using the helper to select good defaults, > but I'd rather see the defaults in the attribute configurations themselves. Indeed, this is not yet done this way, because we currently lack what is the common practice in the field.
Some info on what is configured in practice: Cisco: http://www.cisco.com/en/US/docs/wireless/controller/7.4/configuration/guides/system_management/config_system_management_chapter_0101.html#ID1403 "By default, A-MPDU is enabled for priority level 0, 4 and 5 and the rest are disabled. By default, A-MSDU is enabled for all priorities except 6 and 7." Netgear only allows an option to configure A-MPDU or not (not sure if it selectively picks QoS TIDs to enable/disable it on without exposing to the user). http://documentation.netgear.com/wn802tv2/enu/202-10415-01/WN802v2_RM_11Sept08-06-09.html Aruba states that it enables A-MPDU by default but I couldn't find details on whether certain ACs were excluded: http://www.arubanetworks.com/techdocs/ArubaOS_63_Web_Help/Content/ArubaFrameStyles/VirtualAPs/Configuring_a_High_Throu.htm
(In reply to Tom Henderson from comment #8) > Some info on what is configured in practice: > > Cisco: > http://www.cisco.com/en/US/docs/wireless/controller/7.4/configuration/guides/ > system_management/config_system_management_chapter_0101.html#ID1403 > > "By default, A-MPDU is enabled for priority level 0, 4 and 5 and the rest > are disabled. By default, A-MSDU is enabled for all priorities except 6 and > 7." > > Netgear only allows an option to configure A-MPDU or not (not sure if it > selectively picks QoS TIDs to enable/disable it on without exposing to the > user). > http://documentation.netgear.com/wn802tv2/enu/202-10415-01/ > WN802v2_RM_11Sept08-06-09.html > > Aruba states that it enables A-MPDU by default but I couldn't find details > on whether certain ACs were excluded: > http://www.arubanetworks.com/techdocs/ArubaOS_63_Web_Help/Content/ > ArubaFrameStyles/VirtualAPs/Configuring_a_High_Throu.htm Tom, Thanks for the information. It seems some are using A-MSDU by default, others are enabling A-MPDU... Also, no idea whether two-level aggregation is widely supported. So, we should agree on some default values for the simulator. My idea was to enable A-MPDU for AC_BE and AC_VI, but no idea about the maximum default size. It seems some use 65k, while other select 32k. Also, even though some enable A-MSDU by default, if we do so with A-MPDU enabled, we get two-level aggregation being used by default! However, I am not sure most of real implementations do support two-level aggregation... Also, any idea about 802.11ac parameters? Should we use the same parameter values? Or should they get extended?
(In reply to sebastien.deronne from comment #9) > (In reply to Tom Henderson from comment #8) > > Some info on what is configured in practice: > > > > Cisco: > > http://www.cisco.com/en/US/docs/wireless/controller/7.4/configuration/guides/ > > system_management/config_system_management_chapter_0101.html#ID1403 > > > > "By default, A-MPDU is enabled for priority level 0, 4 and 5 and the rest > > are disabled. By default, A-MSDU is enabled for all priorities except 6 and > > 7." > > > > Netgear only allows an option to configure A-MPDU or not (not sure if it > > selectively picks QoS TIDs to enable/disable it on without exposing to the > > user). > > http://documentation.netgear.com/wn802tv2/enu/202-10415-01/ > > WN802v2_RM_11Sept08-06-09.html > > > > Aruba states that it enables A-MPDU by default but I couldn't find details > > on whether certain ACs were excluded: > > http://www.arubanetworks.com/techdocs/ArubaOS_63_Web_Help/Content/ > > ArubaFrameStyles/VirtualAPs/Configuring_a_High_Throu.htm > > Tom, > Thanks for the information. > > It seems some are using A-MSDU by default, others are enabling A-MPDU... > Also, no idea whether two-level aggregation is widely supported. So, we > should agree on some default values for the simulator. > > My idea was to enable A-MPDU for AC_BE and AC_VI, but no idea about the > maximum default size. It seems some use 65k, while other select 32k. Also, > even though some enable A-MSDU by default, if we do so with A-MPDU enabled, > we get two-level aggregation being used by default! However, I am not sure > most of real implementations do support two-level aggregation... > > Also, any idea about 802.11ac parameters? Should we use the same parameter > values? Or should they get extended? I don't have any information about ac parameters. For 11n at least, I would be fine to disable A-MSDU by default and enable A-MPDU for those two ACs, and use whichever default (65K or 32K) you decide upon.
Ok, then I suggest to keep similar parameters for 802.11ac. If we later find some more information, this could still be updated.
Latest changes updated in the code review: https://codereview.appspot.com/281230043/
new patch set added to the review
pushed in changeset 11854:7c60a9f8f271