MaintainersJune2024
Main Page - Current Development - Developer FAQ - Tools - Related Projects - Project Ideas - Summer Projects
Installation - Troubleshooting - User FAQ - HOWTOs - Samples - Models - Education - Contributed Code - Papers
This meeting is open to anyone interested.
Date/Time/Venue
Thurs. June 6, 2024 10:00 AM Barcelona Time (08:00 UTC)
Agenda
10:00-12:30 session:
- ns-3 NR module coordination (Tom Henderson and CTTC)
- possible use of nr namespace and removal of 'Nr' prefix on most symbols
- possible removal of service access point API objects
- new helpers for sidelink (and nr), and configuration management
- plan for migration of V2X out of ns-3-dev/lte and for merging v2x with main branch
14:00-15:30 session:
- How should ns-allinone-3.43 be organized? Docker? NetAnim? Bake? (Tom Henderson)
- Start/stop times for ns-3 logging !636
16:00-17:30 session:
- Project governance (Tom Henderson)
- Possible uses for remaining consortium funding (Tom Henderson)
- website work
- hosting contract
- strongly-typed units Merge Request !1887
Lingering issues that we could discuss in one of the meeting sessions
- Next steps with C++ namespaces: Merge Request !1906
- Random variable assignments to streams
Minutes
Attendees: Tom Henderson, Sandra Lagen, Biljana Bojovic, Katerina Koutlia, Amir Ansari, Hamid, Erfan Mozaffari, Pasquale Imputato, Stefano Avallone, Felipe Gomez Cuba, Gabriel Ferreira, Vladimir Zelenkovski, Drew Spitzer, George Frangulea, Eduardo Almeida (remote), Peter Barnes (remote), Alberto Gallegos (remote).
next steps with namespaces
Tom relayed a concern raised by Peter that our namespaces work is incomplete because we are still duplicating module/namespace names in the symbol names, and the helpers are not include. He prefers to not see constructs like ``wifi::WifiHelper`` in the long run; it can become wifi::Helper and transition can be mitigated by using statements. Tom also supported this goal based on his recent experience with the nr module.
Tom identified an issue that string-based TypeIds have not yet been updated (e.g. ns3::BasicEnergySource should become ns3::energy::BasicEnergySource) and that transition is not supported by using statements.
Regarding the next steps for a heavily used module (wifi), Stefano indicated that this was not an urgent priority. Eduardo suggested that we wait a release cycle (until past ns-3.43) to evalute how lr-wpan and energy module transitions have gone, and that we merge any future namespace changes early in a release cycle.
Change of Lte EpsBearer type from enum to class enum
We discussed this at some length and LTE maintainers decided that in this specific case, because of the impact on LTE examples for this widely used enum, to leave it as a plain enum. If the issue is reopened in the future for some reason, the enum class should be moved outside of the class EpsBearer.
random variable stream assignment
The problem of automatic random variable stream assignments becoming perturbed by scenario changes continues to lead to unexpected results that lead to debugging efforts. The use of AssignStreams at the helper level is not foolproof, and further, the common practice of chaining the output of AssignStreams to the next invocation of AssignStreams is contributing to the problem.
Tom mentioned that two improvements that would solve most issues would be to be able to easily dump all of the stream assignments to a debug output file to search for missing assignments, and to avoid chaining AssignStreams() calls together.
Biljana asked about whether there could be some automatic stream assignments that localized the effect of perturbed changes, and suggested a possible approach that involved creating a pool of streams that could be assigned to each possible object type, and serially assign streams from those pools in an automatic way, thereby removing the burden of stream assignment from the simulation author. Tom replied that he did not think it was possible to do this in a completely failsafe way, unless simulation objects had logical names that persisted across different simulation instances, but things like Config paths can be perturbed across simulation runs. The meeting concluded that more work was needed on this point but there was no obvious answer yet.
nr module plan
Tom shared his future refactoring plans for nr module and v2x branch integration. First step will be to copy/rename LTE RLC and above, and also the EPC, to make nr module completely independent of lte module. Tom will wrap LTE moved code into an nr nested namespace, allowing EPC classes to be left with the same name (e.g., EpcPgw and nr::EpcPgw), and the "Lte" prefix will be dropped (e.g., LteUeRrc will become nr::UeRrc). This could pave the way for inclusion of the whole module into the nr nested namespace.
The next step will be to merge v2x-lte-dev and nr-v2x-dev into this new nr module. Separately, Tom plans to develop some new link-to-system mapping for error models for sidelink mode 2 fading channels, and to check/validate the current downlink error model.
Tom advocated for the removal of the Service Access Point (SAP) interface classes throughout the nr RAN layers, because they hinder cross-layer modifications to classes, and are dated (based on 4G Femto Forum specs) and not apparently adhered to in real implementations. Katerina expressed reservation about this step, stating that she thought it offered more clarity about the architectural separation of layers. Tom mentioned that we can use C++ inheritance (base class enforces the API) to accomplish similar clarity, but making it easier for users to modify the interfaces in their own implementation to do research, and also mentioned that our C++ attribute system requires Ptr access to all objects, and these cannot cross such boundaries (leading to unusal paths such as accessing the Mac scheduler through the BandwithPartManager instead of through the Mac). There was no agreement at this meeting to remove these classes, so they will remain for the time being.
Another problem to be addressed is the lengthy and verbose configuration of nr examples, especially in the V2X code. The meeting discussed the potential to do more with managing configuration via outside configuration files, such as the ConfigStore (text or XML, possibly JSON, file formats). However, scenarios can't be fully exported to configuration files because ns-3 lacks a high-level language like OMNeT++ NED to describe topology. Gabriel suggested the use of standardized YANG/NETCONF instead of custom solutions such as NED. Tom expressed the view that some people would prefer to run simulation campaigns by managing default and command-line values in external files, and that we could perhaps reduce the size of some of our example programs if we could refer to external files that illustrated key default values that could be changed. If the ConfigStore were extended to manage CommandLine arguments, then the system could be more extensible.
How should ns-allinone-3.43 be organized?
Tom mentioned that the current bundling of netanim, bake, and ns-3 is not really useful to many people-- most people surveyed are just git cloning from ns-3-dev and checking out the release that they want, or git cloning some fork of ns-3. However, he mentioned that he would prefer instead to start releasing bundles of tested contributed modules and declaring that as 'allinone' (e.g., waiting a month until the ns-3.xx release is made, and then publishing ns-allinone-3.xx that includes copies of all of the aligned contrib modules that can be drawn from the App Store). Tom plans to work on this in the current release cycle.
Start/stop times for ns-3 logging
The meeting agreed that this would be a useful feature, to limit the scope of log output to time ranges (see !636). Pasquale mentioned that limiting the scope of the context would also be useful. Katerina volunteered to try to push !636 along.
Strongly-typed units
Peter expressed his opinion that the project should not adopt a custom units library but instead adopt an externally maintained one. Stefano said that wifi maintainers were likely to adopt a custom solution (possibly Jiwoong Lee's solution) in the meantime if the project could not yet come to consensus.
Peter advocated mp-units because a number of contributors have banded together to try to get this solution into a future C++ standard library; in the meantime, it is distributed as a header-only library under MIT license. The options to actually include it, were we to adopt it, would be to include as a vendored-in header, to use CMake integration for git submodule or conan/vcp integration.
Stefano asked Peter what would happen to existing units support, and whether these strongly typed units could be used in the Attribute system. Peter replied that the Boost::length in the core would go away, DataRate would probably go away, but Time class may not be replaced, because we have some specific requirements on this class (integer representation, default nanosecond precision) so likely there would need to be some converter back and forth between mp-units time and ns-3 Time. Tom wondered whether this will expose us to more float-to-int time conversion portability issues. As for Attributes, Peter said that mp-units has some string-based representations that could be leveraged, but Value wrappers for the non-string types need to be explored. Tom also pointed out that non-linear conversions (dBW or dBm to W) are not supported, and Peter acknowledged that mp-units would need to be extended in this regard.
Action items were that Peter urged everyone to read the mp-units paper, and Peter will explore some of the open questions above, and we will discuss again at a future maintainers meeting. Eduardo said that the support could be gradually rolled out; we could start to use it in a subset of our modules once enabled.
Governance
Tom shared that he was working on publishing a governance model that is adapted from several similar open source projects, and has shared an initial draft with a few longtime maintainers. Once he processes all of the comments, it will be posted for broader review. He shared that the guiding principles are:
- contributors to open source want to understand if the core team and the governance is aligned with their interests, and how conflict resolution or behavior issues may be handled
- the primary stakeholders are the maintainers working on the software day-to-day, and they should have the strongest voices in guiding the project, but there also needs to be room for people less connected to software maintenance to serve in prominent roles, such as community building, onboarding, outreach, etc.
- some maintainers do not want to get involved in things other than the code that they are managing, while others may want to maintain code and be active in other aspects
- as a result, a governance structure defining two overlapping groups of contributors (maintainers, steering council) is being developed.
- the governance should be as lightweight as possible and scale to smaller or larger groups of contributors than we presently have