Nsnam - Recent changes [en]

MaintainersApr2026

Tomh — Fri, 01 May 2026 16:26:58 GMT

add minutes for April 24 meeting

← Older revision		Revision as of 16:26, 1 May 2026
Line 52:		Line 52:

	2) Inclusion of DTN models in the mainline		2) Inclusion of DTN models in the mainline

			== Minutes for April 24 ==

			Attendees: Anders Martinsson, Tom Henderson, Eduardo Almeida, Alberto Gallegos Ramonet

			Minutes from Tom Henderson, edited by Alberto and Eduardo

			Agenda:
			1. Use of CMake Presets
			2. Inclusion of DTN models in the mainline
			3. How to promote smaller MRs for easier reviews

			Anders introduced himself as the submitter of a recent patch series to update DCE environment. He said that other developers were involved at his company and they were using it to test a secure reliable transport protocol. Tom said that he was planning to get to DCE patches once mp-units work died down.

			Alberto and Eduardo discussed the history of the CMake Presets to Tom who does not use VScode and wasn't fully aware of the issues. Eduardo mentioned that we currently use .ns3rc for this kind of configuration control but it would be nicer to use CMake Presets since it is the standardized way.
			An initial attempt to use CMake Presets was introduced last month in !2763 by the CTTC team as a way to use configurations that allow the use of Sionna spectrum models. However, as described in !2822, the introduction of CMake Presets forced users using the VsCode IDE to chose one preset (VsCode default behavior when using CMake Presets) without the possibility of choosing different build variants or compilers outside the established presets. Gabriel reverted the situation by renaming the CMake Presents configuration file to use a different extension but more work is needed on a better solution if the use of presets are to be introduced.

			We discussed DTN and the pros and cons of adding this to the mainline or to the app store. Alberto is in favor of adding new models to the main line assuming that they are for the common benefit ( e.g., based on specifications, standards, current RFCs, etc) and have a maintainer. In the same line of thought, he thinks that models in the main line that do not have a maintainer or have unresponsive maintainers should be moved to the app store. Accepting new contributions has the possible side benefit of attracting more long term maintainers. If the maintainers of those models become uninterested in maintaining or unresponsive, it is possible to move them to the app store.

			Eduardo pointed out that the app-store have evolved and serve multiple purposes, among them: A place where worthy unmaintained projects are stored and where private groups keep visibility of projects actively maintained outside of the main line.

			However, the general sentiment is that when possible, we ought keep ns-3 mainline lean, and it is not clear where DTN lands as a result of these tensions.

			Tom mentioned that a second benefit of having MRs submitted to the mainline is that they obtain code reviews; the ns-3-contributed-modules review site has never taken off and is ignored by maintainers. Still, it seems that the attendees were possibly in favor of reducing the modules in ns-3-dev, adding more to the app store, and making it easier for users to discover and clone modules of interest (kind of like 'bake' is doing for DCE, but possibly through extending the ns3 script or CMake).

			Tom mentioned his difficulty with reviewing large MRs. Eduardo said he wasn't in favor of a hard CI requirement on MR size and Tom said he wasn't serious about this and agreed that softer reminders (please regenerate your MR in smaller chunks) would be better. Tom said that he also wants to see the overall plan of where things are going, rather than having the new module revealed to him piece-by-piece with small MRs, so having a fully built-out branch that is publicly available for review to accompany the MRs is also needed. Eduardo volunteered to review our contributing documentation to see if there is an opportunity to emphasize "one MR per topic and make as small as possible."

	== Recent maintainers meetings ==		== Recent maintainers meetings ==

Summer Projects

Tomh — Fri, 01 May 2026 15:16:52 GMT

Google Summer of Code 2026

← Older revision		Revision as of 15:16, 1 May 2026
Line 7:		Line 7:
	The organizational admins are Tommaso Pecorella, and Mohit P. Tahiliani.		The organizational admins are Tommaso Pecorella, and Mohit P. Tahiliani.

			We are happy to announce that the following five projects have been accepted:

			* '''Nipuna Dulara''', [https://summerofcode.withgoogle.com/programs/2026/projects/nQxxo1N3 Energy Consumption Modeling and Power Aware Extensions for 5G LENA]
			* '''Anuka Hettiarachchi''', [https://summerofcode.withgoogle.com/programs/2026/projects/G2dYeVu6 Integrating 5G NR module with ns-3-ai]
			* '''Kedar Kisan''', [https://summerofcode.withgoogle.com/programs/2026/projects/PCXPdFoD Flent Application API Integration and Validation in ns-3]
			* '''Usham Roy''', [https://summerofcode.withgoogle.com/programs/2026/projects/wHBM2psz 6LoWPAN Mesh Under Routing Enhancements with Trickle Suppression in ns3]
			* '''Manmita Das''', [https://summerofcode.withgoogle.com/programs/2026/projects/Wl61Gzov Switched Ethernet]

			Background material:
	* [[GSOC2026Projects \| Project Ideas Page]]		* [[GSOC2026Projects \| Project Ideas Page]]
	* [[GSOC2026ContributorGuide \| ns-3's GSoC Contributor Guide]]		* [[GSOC2026ContributorGuide \| ns-3's GSoC Contributor Guide]]

MaintainersApr2026

Tomh — Fri, 24 Apr 2026 14:36:24 GMT

Agenda for April 24

← Older revision		Revision as of 14:36, 24 April 2026
(One intermediate revision by the same user not shown)
Line 46:		Line 46:

	2) General roundtable on roadmap/priorities (what does each maintainer want to prioritize for ns-3.48 and beyond?)		2) General roundtable on roadmap/priorities (what does each maintainer want to prioritize for ns-3.48 and beyond?)

			Alberto proposed:

			1) Use of CMake presets? Yes or no

			2) Inclusion of DTN models in the mainline

	== Recent maintainers meetings ==		== Recent maintainers meetings ==

Nsnam:Current events

Tomh — Tue, 21 Apr 2026 03:30:54 GMT

Upcoming Events

← Older revision		Revision as of 03:30, 21 April 2026
Line 3:		Line 3:

	== Upcoming Events ==		== Upcoming Events ==
	* Friday ~~March 13~~: [[~~MaintainersMar2026~~\| maintainers meeting]]		* Friday April 24: [[MaintainersApr2026\| maintainers meeting]]
	* ns-3 is part of [https://www.nsnam.org/wiki/Summer_Projects#Google_Summer_of_Code_2026 Google Summer of Code 2026]		* ns-3 is part of [https://www.nsnam.org/wiki/Summer_Projects#Google_Summer_of_Code_2026 Google Summer of Code 2026]
	* The [https://www.nsnam.org/research/icns3/icns3-2026/ 2026 edition of ICNS3] will be held October 19-21.		* The [https://www.nsnam.org/research/icns3/icns3-2026/ 2026 edition of ICNS3] will be held October 19-21.

MaintainersApr2026

Tomh — Wed, 08 Apr 2026 13:53:25 GMT

Minutes for April 3

← Older revision		Revision as of 13:53, 8 April 2026
(2 intermediate revisions by the same user not shown)
Line 9:		Line 9:
	Friday April 24, 15h00 UTC, Jitsi Meet: https://meet.jit.si/moderated/f77dc878bc2167da942669fe1bc99804dd706a60a97752c6773d1afd1fdaaf3b		Friday April 24, 15h00 UTC, Jitsi Meet: https://meet.jit.si/moderated/f77dc878bc2167da942669fe1bc99804dd706a60a97752c6773d1afd1fdaaf3b

	== Agenda ==		== Agenda for April 3 ==

	~~Some items left from last meeting:~~		Update on strongly-typed units (Tom)

	~~1) How~~ to ~~promote smaller MRs~~ for ~~review?~~ ~~Should~~ our ~~CI system fail (perhaps as~~ a ~~last stage~~ of ~~testing~~) a MR that ~~exceeds~~ a ~~certain number~~ of ~~lines~~ of code ~~changed~~? (~~Tom~~)		- Proposing to adopt the [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2768 mp-units MR] and quickly port the wifi module for ns-3.48

			== Minutes for April 3 ==

			Attendees: Tom Henderson, Stefano Avallone, Peter Barnes

			Minutes taken by Tom Henderson

			The meeting discussed the mp-units MR and si-units-v2 MR. Tom intends to close the nholthaus proposal in favor of mp-units.

			Tom expressed his interest in adopting the mp-units MR due to potential alignment with the future standard, and to avoid the project having to maintain its own units library. He is happy with how the wifi port turned out, and aside from cppyy alignment, he would be inclined to push it now and finish further work in-tree. Peter mentioned that our experience with Waf to CMake migration suggests that there is a long term maintenance benefit of aligning with external best practices rather than doing our own thing. Stefano expressed interest in future (potential) standard library alignment and found a [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2768#note_3220455766 Reddit post] about a recent presentation to the standards committee by the mp-units lead author, suggesting that it is still on track.

			We discussed potential ns3::Time compatibility; we would have to give up runtime resolution setting and make it instead a compile-time setting, which might create some inflexibility if ns-3 is distributed as a library package, and might force people to document which resolution the simulator was compiled with.

			Lingering issues:

			- how much backward compatibility to support? Stefano raised one such issue in the tracker (whether we support StringValue() on value classes without providing the units suffix in the string). Do we want to keep the trace sources exporting double types, or give this up? What about ChannelSegments() types? Tom tested backward compatibility of our current wifi examples and 37/51 would still work after the port, if we kept things as they are now.

			- cppyy doesn't yet support std::format (which is included by mp-units), and Gabriel is inquiring upstream about this. We can probably work around this with wrappers like Gabriel already introduced for ns-3 Time but Tom hasn't discussed the alternatives much with him yet.

			- whether people agree with the decisions taken on naming, which new headers to introduce, how the mp-units namespace is being brought into ns3 namespace, etc.

			- would we want to add library-independent syntax for Wi-Fi to ease rebasing for your out-of-tree code? Stefano brought up supporting "MHz_t{20}" in particular and wanting to be able to define constants in a way that they would work for both si-units and mp-units in the near term. With regard to this particular issue, Tom will post options and constraints in the tracker, but Peter was open to defining wrappers if we localized them to wifi module specifically (and use the mp-units library's idiomatic syntax elsewhere in ns-3).

			== Agenda for April 24 ==

	~~2) General roundtable on roadmap/priorities (what does each maintainer want to prioritize~~ for ~~ns-3~~.~~48 and beyond?)~~		Please propose agenda items for this meeting.

	~~3) Update on strongly-typed units (Tom)~~		Some items left from the March meeting:

	~~- Proposing~~ to ~~adopt the [https://gitlab.com/nsnam/ns-3-dev/-/merge_requests/2768 mp-units~~ MR~~] and quickly port the wifi module for ns-3.48~~		1) How to promote smaller MRs for review? Should our CI system fail (perhaps as a last stage of testing) a MR that exceeds a certain number of lines of code changed? (Tom)

	~~Other items TBD. I'm sure we could discuss coding agents again~~.		2) General roundtable on roadmap/priorities (what does each maintainer want to prioritize for ns-3.48 and beyond?)

	== Recent maintainers meetings ==		== Recent maintainers meetings ==

GSOC2026Projects

Tomh — Sun, 05 Apr 2026 15:52:02 GMT

fix spelling

← Older revision		Revision as of 15:52, 5 April 2026
Line 141:		Line 141:
	* Use !2645 to modify all or in part the `Rip` protocol.		* Use !2645 to modify all or in part the `Rip` protocol.

	=== Ping and ~~TraverouteV4~~ enhancements ===		=== Ping and TracerouteV4 enhancements ===

	Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].		Mentors: [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella], [TBD].

	The Ping and ~~TraverouteV4~~ ns-3 application have some small limitations.		The Ping and TracerouteV4 ns-3 application have some small limitations.

	In particular 2 of them are annoying.		In particular 2 of them are annoying.