GSOC2020Projects - Revision history

Tomh: /* TCP Prague model for ns-3 */

2020-03-24T20:45:26Z

TCP Prague model for ns-3

← Older revision		Revision as of 20:45, 24 March 2020
Line 295:		Line 295:
	Mentor: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]		Mentor: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

	TCP Prague is being developed as part of the L4S project. TCP Prague is designed to provide both high throughput and low latency, using more fine-grained congestion control feedback, and it has to coexist with legacy TCP congestion controllers such as TCP Cubic. Although ns-3 has models for the [https://gitlab.com/tomhend/modules/l4s-evaluation L4S components], to date, we have mostly been using DCTCP as a surrogate. There are still many research questions for TCP Prague, including whether it can do [https://arxiv.org/abs/1911.00710 RFC 3168 queue detection and fallback], how to [https://github.com/JoakimMisund/PacedChirping pace out packets], integrating [https://tools.ietf.org/html/draft-ietf-tcpm-rack-04 TCP RACK] with it, how it may respond to packet aggregation in the network, and how it can perform across a range of coexistence scenarios. Joakim Misund has already started a [https://gitlab.com/JoakimMisund/l4s-evaluation/tree/tcp-prague TCP Prague implementation for ns-3]. This GSoC project would work to develop TCP Prague further and compare it against the Linux implementation, implementing the features that are not yet done such as RFC 3168 queue detection.		TCP Prague is being developed as part of the L4S project. TCP Prague is designed to provide both high throughput and low latency, using more fine-grained congestion control feedback, and it has to coexist with legacy TCP congestion controllers such as TCP Cubic. Although ns-3 has models for the [https://gitlab.com/tomhend/modules/l4s-evaluation L4S components], to date, we have mostly been using DCTCP as a surrogate. There are still many research questions for TCP Prague, including whether it can do [https://arxiv.org/abs/1911.00710 RFC 3168 queue detection and fallback], [https://datatracker.ietf.org/meeting/interim-2020-tsvwg-01/materials/slides-interim-2020-tsvwg-01-sessa-l4s-tcp-prague-update.pdf RTT independence], how to [https://github.com/JoakimMisund/PacedChirping pace out packets], integrating [https://tools.ietf.org/html/draft-ietf-tcpm-rack-04 TCP RACK] with it, how it may respond to packet aggregation in the network, and how it can perform across a range of coexistence scenarios. Joakim Misund has already started a [https://gitlab.com/JoakimMisund/l4s-evaluation/tree/tcp-prague TCP Prague implementation for ns-3]. This GSoC project would work to develop TCP Prague further and compare it against the Linux implementation, implementing the features that are not yet done such as RFC 3168 queue detection.
	* ''Required Experience:'' Familiarity with C++ and TCP		* ''Required Experience:'' Familiarity with C++ and TCP
	* ''Bonus Experience:'' Familiarity with L4S.		* ''Bonus Experience:'' Familiarity with L4S.
Line 302:		Line 302:
	** NetDev 0x13 talk on [https://www.youtube.com/watch?v=GyXwvRKW0QE TCP Prague requirements]		** NetDev 0x13 talk on [https://www.youtube.com/watch?v=GyXwvRKW0QE TCP Prague requirements]
	** NetDev 0x13 talk on [https://www.youtube.com/watch?v=UCUtudQ33Pc Paced Chirping]		** NetDev 0x13 talk on [https://www.youtube.com/watch?v=UCUtudQ33Pc Paced Chirping]
			** The Linux implementation is maintained at: https://github.com/L4STeam/linux
			** This recent talk at the IETF contains latest status: https://datatracker.ietf.org/meeting/interim-2020-tsvwg-01/materials/slides-interim-2020-tsvwg-01-sessa-l4s-tcp-prague-update.pdf

	==== NetDevice up/down consistency and event chain ====		==== NetDevice up/down consistency and event chain ====

Tomh: /* Project Ideas */

2020-03-19T15:46:36Z

Project Ideas

← Older revision		Revision as of 15:46, 19 March 2020
Line 127:		Line 127:

	Hint: See the radio link failure test suite		Hint: See the radio link failure test suite

			==== App Store improvements ====

			Mentors: [mailto:abhijithabhayam@gmail.com Abhijith Anilkumar], [mailto:adadeepak8@gmail.com Ankit Deepak]

			The [https://apps.nsnam.org ns-3 App Store] is a platform to advertise the availability of third-party contributed modules to ns-3. The maintainers of the app store propose some next steps in its evolution that would be suitable for a GSoC project.

			1. Develop a CI/CD server that can run tests integrating a new module based on the Bakefile. This will involve checking all dependencies and running the tests and mailing out results. [https://ns-buildmaster.ee.washington.edu:8010/ Jenkins] is a candidate system for this; we would need this project to develop the scripts and the ability for users to make use of something like Jenkins. Another candidate system is to reuse GitLab.com CI/CD.

			2. Have a new Django module in the AppStore that lets developers upload their new apps (can be a Bakefile with link to repository or a Bakefile with tar file). Another feature that we can use is that the developers can be asked to tag a release in GitLab/GitHub so that the corresponding repository can be picked up easily. From here, we trigger the testing on the dedicated server that is present, and fetch the results. From the AppStore side, we display the results and let them know if there are any issues. Once this is done, the developer can "Publish" the module adding necessary documentation. Basically, this remove the manual intervention of verifying whether the module is ready to be published. Making the AppStore aware of CI/CD lets us have something similar to https://pkg.julialang.org/docs/, where we can showcase the build status and dependencies instead of relying on manual update.

			3. A comprehensive app users guide and app developers guide are still to be written; they could be part of this project.

			4. The AppStore should be made aware of new releases of the mainline, and it can run the Apps against the new versions automatically and see if the module successfully compiles. If it does, it can notify the developer to update the module if necessary. If not, developer can be notified of the current status as well. (Mozilla does this for their add-ons whenever a new version of Firefox is released).

			* Required Experience: Python, Django
			* Bonus Experience: C++

	==== Migrate contributed code to App Store ====		==== Migrate contributed code to App Store ====

Tomh: /* Project Ideas */

2020-03-19T04:07:32Z

Project Ideas

← Older revision		Revision as of 04:07, 19 March 2020
Line 95:		Line 95:
	* ''For more information:'' https://www.nsnam.org/docs/dce/manual-quagga/html/getting-started.html		* ''For more information:'' https://www.nsnam.org/docs/dce/manual-quagga/html/getting-started.html

	==== Migrate contributed code to ~~apps~~ ====		==== LTE module RRC improvements ====

			Mentors: [mailto:zali@cttc.es Zoraze Ali], [mailto:tomh@tomh.org Tom Henderson]

			Fraunhofer ESK previously published extensions to ns-3 LTE, called [https://mailman.isi.edu/pipermail/ns-developers/2018-December/014629.html ELENA], for RRC improvements around radio link failure (RLF) and IDLE mode models. A portion of this work (the RLF model) was improved and merged to ns-3.30 release by Zoraze Ali, but several features were not included in the mainline; the five missing features are listed in this [https://mailman.isi.edu/pipermail/ns-developers/2019-February/014668.html email to ns-developers list]. Meanwhile, the Fraunhofer team has released [https://gitlab.cc-asp.fraunhofer.de/elena-ns3-lte/elena version 1.1 of ELENA]. This GSoC project will continue to add features from ELENA to ns-3, in the order suggested by Zoraze (and also tracking ELENA 1.1 changes).

			'' LTE RRC challenge project''

			As part of the application, an applying student should consider attempting the following exercise. Currently, the UE PHY layer for RLF detection sends an out-of-sync indication to the UE RRC if it is unable to decode 20 consecutive frames. We suggest trying to generate a patch with the following changes:

			* Extend the code such that the UE PHY sends an intermediate notification to UE RRC. That is, the UE PHY should send a notification to UE RRC if it is unable to decode 10 consecutive frames.
			* The UE RRC, upon receiving this intermediate notification, should send an ideal RRC message to the eNB RRC by including its IMSI. This should work for both Ideal and Real RRC protocol.
			* The eNB RRC, upon receiving this notification should fire a new trace, i.e., a new trace source, which would have IMSI as its parameter. The student is free to choose any name for this trace source, e.g., “MidOutOfSync”.
			* Implement a trace sink for the above new trace in lena-radio-link-failure.cc example.

			Hint: Check the Radio link failure section in LTE design documentation.

			To confirm that it works, write a test, which simulates an LTE EPC scenario with one eNB and one UE. The UE at 0.5 sec jumps 7000 meters away from the eNB (we assume that UE was successfully attached to the eNB). This would trigger the RLF. The goal of the test is to check that at the end of the simulation the “PhySyncDetection” trace with type “Notify out of sync” at UE RRC is triggered exactly after 100 ms (i.e., 10 consecutive frames) of new “MidOutOfSync” trace at the eNB. The parameters are:
			* eNB initial position = 0, 0, 30
			* eNB TX power = 43 dBm
			* UE initial position = 10, 0, 1.5
			* UE TX power = 23 dBm
			* Pathloss model = LogDistancePropagationLossModel
			** Exponent = 3.9
			** Reference Loss = 38.7 dB
			** Reference distance = 1 m
			* N310 = 1
			* N311 = 1
			* T310 = 1 sec
			* One UDP downlink application with the data rate = 18.6Mbps

			Hint: See the radio link failure test suite

			==== Migrate contributed code to App Store ====

	Mentors: [mailto:tomh@tomh.org Tom Henderson]		Mentors: [mailto:tomh@tomh.org Tom Henderson]
Line 103:		Line 136:
	* 802.11ah		* 802.11ah
	* WiGig		* WiGig
			* Switched Etherent model
			* Compound TCP
	* Others TBD		* Others TBD

Line 171:		Line 206:
	This project idea is a bit loosely defined. As a result, we have received inquiries seeking more guidance on how to proceed. Here are some ideas of what we would like to see from an application if it were to be competitive for selection in GSoC 2020.		This project idea is a bit loosely defined. As a result, we have received inquiries seeking more guidance on how to proceed. Here are some ideas of what we would like to see from an application if it were to be competitive for selection in GSoC 2020.

	'''1) Netanim challenge project'''		''1) Netanim challenge project''

	Demonstrate that you can develop a new animation, and list the issues that you may have encountered in doing so. For example, below is a graphic and animation on virus spread from the Washington Post (March 15, 2020). This type of animation can be created in ns-3 with netanim. If an applicant were able to write an ns-3 program that generated an animation that showed the nodes infecting other nodes and then recovering, and rendered some animation in approximately the same way as shown, it would convey some level of readiness and expertise to the review committee. The ns-3 program should support different random variable run numbers, use existing mobility models (and ability to change those parameters), and support different probabilities of infecting other nodes according to some criteria (such as if the node moved within a configurable delta distance of another node, it infected that node with a probability p), and different lifetime of infection during which the node is contagious (such as constant number of days or some random variable around a mean). The animation would show the nodes changing color from healthy to sick to recovered. Some way to render the counts of healthy/infected/recovered and the time-varying CDF of infections would be a nice bonus and demonstrate some expertise with Qt.		Demonstrate that you can develop a new animation, and list the issues that you may have encountered in doing so. For example, below is a graphic and animation on virus spread from the Washington Post (March 15, 2020). This type of animation can be created in ns-3 with netanim. If an applicant were able to write an ns-3 program that generated an animation that showed the nodes infecting other nodes and then recovering, and rendered some animation in approximately the same way as shown, it would convey some level of readiness and expertise to the review committee. The ns-3 program should support different random variable run numbers, use existing mobility models (and ability to change those parameters), and support different probabilities of infecting other nodes according to some criteria (such as if the node moved within a configurable delta distance of another node, it infected that node with a probability p), and different lifetime of infection during which the node is contagious (such as constant number of days or some random variable around a mean). The animation would show the nodes changing color from healthy to sick to recovered. Some way to render the counts of healthy/infected/recovered and the time-varying CDF of infections would be a nice bonus and demonstrate some expertise with Qt.
Line 179:		Line 214:
	Any applicant who is able to write some code to animate something such as above can skip the other GSoC 2020 patch requirement project.		Any applicant who is able to write some code to animate something such as above can skip the other GSoC 2020 patch requirement project.

	'''2) Open issues'''		''2) Open issues''

	Applicant should review the open issues on our legacy Bugzilla tracker: https://www.nsnam.org/bugzilla/buglist.cgi?bug_status=__open__&content=&no_redirect=1&order=Importance&product=netanim&query_format=specific		Applicant should review the open issues on our legacy Bugzilla tracker: https://www.nsnam.org/bugzilla/buglist.cgi?bug_status=__open__&content=&no_redirect=1&order=Importance&product=netanim&query_format=specific
Line 187:		Line 222:
	Another recently discovered issue is how to allow NetAnim to support the new Wifi physical layer: https://gitlab.com/nsnam/ns-3-dev/-/issues/127		Another recently discovered issue is how to allow NetAnim to support the new Wifi physical layer: https://gitlab.com/nsnam/ns-3-dev/-/issues/127

	'''3) Documentation and examples'''		''3) Documentation and examples''

	The existing netanim documentation is here: https://www.nsnam.org/docs/release/3.30/models/html/animation.html and also on wiki pages (https://www.nsnam.org/wiki ; search for the term 'Netanim'). If we were to include a new standalone netanim document, such as we already do for the ns-3 tutorial, what structure/outline would it take? What parts of netanim presently lack much documentation?		The existing netanim documentation is here: https://www.nsnam.org/docs/release/3.30/models/html/animation.html and also on wiki pages (https://www.nsnam.org/wiki ; search for the term 'Netanim'). If we were to include a new standalone netanim document, such as we already do for the ns-3 tutorial, what structure/outline would it take? What parts of netanim presently lack much documentation?
Line 193:		Line 228:
	Planning also to extend the existing ns-3 tutorial with netanim examples would also be a worthwhile part of a project plan.		Planning also to extend the existing ns-3 tutorial with netanim examples would also be a worthwhile part of a project plan.

	'''4) Enhancements'''		''4) Enhancements''

	Applicant can propose to work on some of the above suggested enhancements (like conversion from XML to JSON format). Explain how Netanim might support parsing of JSON-formatted traces.		Applicant can propose to work on some of the above suggested enhancements (like conversion from XML to JSON format). Explain how Netanim might support parsing of JSON-formatted traces.

Tomh: update TCP projects

2020-03-19T00:10:35Z

update TCP projects

← Older revision		Revision as of 00:10, 19 March 2020
Line 239:		Line 239:
	** [https://tools.ietf.org/html/draft-morton-tsvwg-lightweight-fair-queueing-00 Lightweight FQ]		** [https://tools.ietf.org/html/draft-morton-tsvwg-lightweight-fair-queueing-00 Lightweight FQ]

	==== ~~Cheap Nasty Queuing (CNQ) and Lightweight Fair Queuing (LFQ) models~~ for ns-3 ====		==== TCP Prague model for ns-3 ====

	Mentor: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani~~], [mailto:tomh@tomh.org Tom Henderson~~]		Mentor: [mailto:tomh@tomh.org Tom Henderson], [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani]

	~~Cheap Nasty Queuing (CNQ) and Lightweight Fair Queuing (LFQ) are recently proposed Internet drafts in IETF~~. ~~CNQ provides a single-instance Active Queue Management (AQM) and basic sparse-flow prioritisation whereas LFQ~~ is ~~expected~~ to provide throughput ~~fairness~~, ~~sparse flow prioritization~~ and ~~ordering guarantees while maintaining~~ a ~~small code footprint~~, ~~low memory requirements~~, ~~no multiply operations~~, ~~only two physical queues~~, and ~~only one set~~ of ~~AQM state~~. ~~This project idea is about implementing, testing and documenting CNQ and LFQ in~~ ns-3. ~~These algorithms can be combined with Controlled Delay (CoDel) or CoDel BLUE Alternate (COBALT)~~ to ~~verify~~ the ~~correctness of~~ the ~~implementation~~.		TCP Prague is being developed as part of the L4S project. TCP Prague is designed to provide both high throughput and low latency, using more fine-grained congestion control feedback, and it has to coexist with legacy TCP congestion controllers such as TCP Cubic. Although ns-3 has models for the [https://gitlab.com/tomhend/modules/l4s-evaluation L4S components], to date, we have mostly been using DCTCP as a surrogate. There are still many research questions for TCP Prague, including whether it can do [https://arxiv.org/abs/1911.00710 RFC 3168 queue detection and fallback], how to [https://github.com/JoakimMisund/PacedChirping pace out packets], integrating [https://tools.ietf.org/html/draft-ietf-tcpm-rack-04 TCP RACK] with it, how it may respond to packet aggregation in the network, and how it can perform across a range of coexistence scenarios. Joakim Misund has already started a [https://gitlab.com/JoakimMisund/l4s-evaluation/tree/tcp-prague TCP Prague implementation for ns-3]. This GSoC project would work to develop TCP Prague further and compare it against the Linux implementation, implementing the features that are not yet done such as RFC 3168 queue detection.
	* ''Required Experience:'' Familiarity with ~~queue disciplines and~~ C++ ~~programming.~~		* ''Required Experience:'' Familiarity with C++ and TCP
	* ''Bonus Experience:'' Familiarity with ~~CNQ and LFQ~~.		* ''Bonus Experience:'' Familiarity with L4S.
	* ''Interests:'' Packet Scheduling algorithms
	* ''Difficulty:'' Medium to Hard.		* ''Difficulty:'' Medium to Hard.
	* ''Recommended Reading:''		* ''Recommended Reading:'' see the inline links above, plus:
	** [https:~~//tools.ietf.org/html/draft-morton-tsvwg-cheap-nasty-queueing-01 Internet draft on CNQ]~~		** NetDev 0x13 talk on [https://www.youtube.com/watch?v=GyXwvRKW0QE TCP Prague requirements]
	** ~~[https://tools.ietf.org/html/draft-morton-tsvwg-lightweight-fair-queueing-00 Internet draft~~ on ~~LFQ]~~		** NetDev 0x13 talk on [https://www.youtube.com/watch?v=UCUtudQ33Pc Paced Chirping]
	** [https://~~github~~.~~com/chromi/sce/commits/sce Linux implementation of CNQ]~~
	** [https://github.com/~~chromi/sce/commits/sce Linux implementation of LFQ]~~
	** [https://www.nsnam.org/docs/models/html/queue-discs.html Queue Disciplines in ns-3]

	~~===~~= ~~Google’s BBRv2 congestion control algorithm for ns-3~~ TCP ~~====~~

	~~Mentor: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani~~]~~, [mailto:tomh@tomh.org Tom Henderson]~~

	BBRv2 is an enhanced version of BBR (Bottleneck Bandwidth and RTT), both developed at Google. BBRv2 overcomes the limitations of BBR, such as: no response to packet loss, no response to ECN (Explicit Congestion Notification) and unfairness while coexisting with traditional TCP variants (e.g., CUBIC). A BBR model has been developed for ns-3 but is currently out of the mainline. This project is about merging the available implementation of BBR and subsequently implementing, testing and documenting BBRv2 in ns-3.
	* ~~''Required Experience:'' Familiarity with TCP congestion control algorithms~~
	* ''Bonus Experience:'' Familiarity with BBR and BBRv2
	* ''Interests:'' TCP Congestion Control
	* ''Difficulty:'' Medium to Hard.
	* ''Recommended Reading:''
	** [https://tools.ietf.org/html/draft-cardwell-iccrg-bbr-congestion-control-00 Internet draft on BBR]
	** [https://datatracker.ietf.org/meeting/104/materials/slides-104-iccrg-an-update-on~~-bbr-00 IETF Presentation about BBRv2]~~
	** [https://github.com/google/bbr/blob/v2alpha/net/ipv4/tcp_bbr.c Linux implementation of BBR]
	** [https://github.com/google/bbr/blob/v2alpha/net/ipv4/tcp_bbr2.c Linux implementation of BBRv2]
	** [https://www.~~nsnam.org/docs/models/html/tcp.html TCP models in ns-3]~~
	** [https://github.com/~~Vivek-anand-jain/Reproduce-TCP-BBR-in-ns-3 BBR implementation in ns-3~~]

	==== NetDevice up/down consistency and event chain ====		==== NetDevice up/down consistency and event chain ====

Tomh: /* SCE codepoint for ns-3 TCP and Queue Disciplines */

2020-03-18T23:03:16Z

SCE codepoint for ns-3 TCP and Queue Disciplines

← Older revision		Revision as of 23:03, 18 March 2020
Line 221:		Line 221:
	802.11ah: https://github.com/imec-idlab/IEEE-802.11ah-ns-3		802.11ah: https://github.com/imec-idlab/IEEE-802.11ah-ns-3

	==== SCE ~~codepoint for ns-3~~ TCP ~~and Queue Disciplines~~ ====		==== SCE AQMs and TCP ====

	Mentor: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:tomh@tomh.org Tom Henderson]		Mentor: [mailto:tahiliani.nitk@gmail.com Mohit P. Tahiliani], [mailto:tomh@tomh.org Tom Henderson]

	Some Congestion Experienced (SCE) is a recently proposed codepoint for Explicit Congestion Notification (ECN)~~. The purpose of SCE codepoint is~~ to deliver ~~an early~~ notification of congestion ~~that is building up in the network devices, prior to delivering~~ Congestion Experienced (CE) ~~codepoint~~. This project idea is about implementing, testing and documenting SCE ~~codepoint support~~ in ns-3. ~~It requires modifications to TCP model~~ and ~~queue disciplines in ns~~-~~3. ECN is~~ already supported in ns-3, so implementing SCE does not require major architectural changes to ns-3 codebase.		[https://tools.ietf.org/html/draft-morton-tsvwg-sce-01 Some Congestion Experienced (SCE)] is a recently proposed use of the ECT(1) codepoint for Explicit Congestion Notification (ECN) to deliver earlier notification of congestion than a Congestion Experienced (CE) mark. This approach is an alternative to using ECT(1) to signal the use of [https://www.ietf.org/id/draft-ietf-tsvwg-l4s-arch-06.txt L4S-based congestion controls]. Simulation models [https://gitlab.com/tomhend/modules/l4s-evaluation already exist] for many of the L4S components. This project idea is about implementing, testing and documenting models to experiment with SCE in ns-3. ECN, CoDel AQM, and FQ-CoDel AQM are already supported in ns-3, so implementing SCE does not require major architectural changes to the ns-3 codebase. What will be needed are 1) models for an AQM that supports SCE in a shared queue; specifically, [https://tools.ietf.org/html/draft-morton-tsvwg-codel-approx-fair-01 CodelAF], 2) a TCP that responds appropriately to SCE feedback, such as [https://tools.ietf.org/html/draft-grimes-tcpm-tcpsce-01 TCP-SCE], and 3) scripts to reproduce comparisons with L4S, such as being able to reproduce results [https://github.com/heistp/sce-l4s-bakeoff found here].
	* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.		* ''Required Experience:'' Familiarity with queue disciplines, TCP and C++ programming.
	* ''Bonus Experience:'' Familiarity with SCE ~~codepoint~~.		* ''Bonus Experience:'' Familiarity with SCE or L4S.
	* ''Interests:'' Active Queue Management, Explicit Congestion Notification and TCP.		* ''Interests:'' Active Queue Management, Explicit Congestion Notification and TCP.
	* ''Difficulty:'' Medium to Hard.		* ''Difficulty:'' Medium to Hard.

Tomh: /* NetAnim improvements and examples/documentation */

2020-03-15T19:15:30Z

NetAnim improvements and examples/documentation

← Older revision		Revision as of 19:15, 15 March 2020
Line 175:		Line 175:
	Demonstrate that you can develop a new animation, and list the issues that you may have encountered in doing so. For example, below is a graphic and animation on virus spread from the Washington Post (March 15, 2020). This type of animation can be created in ns-3 with netanim. If an applicant were able to write an ns-3 program that generated an animation that showed the nodes infecting other nodes and then recovering, and rendered some animation in approximately the same way as shown, it would convey some level of readiness and expertise to the review committee. The ns-3 program should support different random variable run numbers, use existing mobility models (and ability to change those parameters), and support different probabilities of infecting other nodes according to some criteria (such as if the node moved within a configurable delta distance of another node, it infected that node with a probability p), and different lifetime of infection during which the node is contagious (such as constant number of days or some random variable around a mean). The animation would show the nodes changing color from healthy to sick to recovered. Some way to render the counts of healthy/infected/recovered and the time-varying CDF of infections would be a nice bonus and demonstrate some expertise with Qt.		Demonstrate that you can develop a new animation, and list the issues that you may have encountered in doing so. For example, below is a graphic and animation on virus spread from the Washington Post (March 15, 2020). This type of animation can be created in ns-3 with netanim. If an applicant were able to write an ns-3 program that generated an animation that showed the nodes infecting other nodes and then recovering, and rendered some animation in approximately the same way as shown, it would convey some level of readiness and expertise to the review committee. The ns-3 program should support different random variable run numbers, use existing mobility models (and ability to change those parameters), and support different probabilities of infecting other nodes according to some criteria (such as if the node moved within a configurable delta distance of another node, it infected that node with a probability p), and different lifetime of infection during which the node is contagious (such as constant number of days or some random variable around a mean). The animation would show the nodes changing color from healthy to sick to recovered. Some way to render the counts of healthy/infected/recovered and the time-varying CDF of infections would be a nice bonus and demonstrate some expertise with Qt.

	[[File:Wash-post.png]] [[File:Netanim-virus.gif]]		[[File:Wash-post.png\|500px]] [[File:Netanim-virus.gif]]

	Any applicant who is able to write some code to animate something such as above can skip the other GSoC 2020 patch requirement project.		Any applicant who is able to write some code to animate something such as above can skip the other GSoC 2020 patch requirement project.

Tomh: /* NetAnim improvements and examples/documentation */

2020-03-15T19:13:08Z

NetAnim improvements and examples/documentation

← Older revision		Revision as of 19:13, 15 March 2020
Line 168:		Line 168:

	[[NetAnim]] is an optional animator for ns-3. It has not been actively developed for a few years. It is written using Qt libraries, and works in an offline mode, meaning that the simulation run outputs a detailed animation trace file that is later imported into NetAnim to visualize the simulation. NetAnim is presently underutilized because of lack of documentation on many features and lack of examples/tutorials around its use. We would be interested in a student who would focus a project around improving the usability, documentation, and examples around NetAnim. Beyond documenting and working on new examples, the following ideas could be explored: 1) replace XML traces with JSON traces, for more compact traces, 2) add a mode in which NetAnim received input data from a named pipe during simulation runtime, rather than having to later open and read a trace file.		[[NetAnim]] is an optional animator for ns-3. It has not been actively developed for a few years. It is written using Qt libraries, and works in an offline mode, meaning that the simulation run outputs a detailed animation trace file that is later imported into NetAnim to visualize the simulation. NetAnim is presently underutilized because of lack of documentation on many features and lack of examples/tutorials around its use. We would be interested in a student who would focus a project around improving the usability, documentation, and examples around NetAnim. Beyond documenting and working on new examples, the following ideas could be explored: 1) replace XML traces with JSON traces, for more compact traces, 2) add a mode in which NetAnim received input data from a named pipe during simulation runtime, rather than having to later open and read a trace file.

			This project idea is a bit loosely defined. As a result, we have received inquiries seeking more guidance on how to proceed. Here are some ideas of what we would like to see from an application if it were to be competitive for selection in GSoC 2020.

			'''1) Netanim challenge project'''

			Demonstrate that you can develop a new animation, and list the issues that you may have encountered in doing so. For example, below is a graphic and animation on virus spread from the Washington Post (March 15, 2020). This type of animation can be created in ns-3 with netanim. If an applicant were able to write an ns-3 program that generated an animation that showed the nodes infecting other nodes and then recovering, and rendered some animation in approximately the same way as shown, it would convey some level of readiness and expertise to the review committee. The ns-3 program should support different random variable run numbers, use existing mobility models (and ability to change those parameters), and support different probabilities of infecting other nodes according to some criteria (such as if the node moved within a configurable delta distance of another node, it infected that node with a probability p), and different lifetime of infection during which the node is contagious (such as constant number of days or some random variable around a mean). The animation would show the nodes changing color from healthy to sick to recovered. Some way to render the counts of healthy/infected/recovered and the time-varying CDF of infections would be a nice bonus and demonstrate some expertise with Qt.

			[[File:Wash-post.png]] [[File:Netanim-virus.gif]]

			Any applicant who is able to write some code to animate something such as above can skip the other GSoC 2020 patch requirement project.

			'''2) Open issues'''

			Applicant should review the open issues on our legacy Bugzilla tracker: https://www.nsnam.org/bugzilla/buglist.cgi?bug_status=__open__&content=&no_redirect=1&order=Importance&product=netanim&query_format=specific

			and comment on whether the issue might be addressed in the GSoC project. Applicant can open any new issues discovered on the gitlab.com/nsnam/netanim.git project.

			Another recently discovered issue is how to allow NetAnim to support the new Wifi physical layer: https://gitlab.com/nsnam/ns-3-dev/-/issues/127

			'''3) Documentation and examples'''

			The existing netanim documentation is here: https://www.nsnam.org/docs/release/3.30/models/html/animation.html and also on wiki pages (https://www.nsnam.org/wiki ; search for the term 'Netanim'). If we were to include a new standalone netanim document, such as we already do for the ns-3 tutorial, what structure/outline would it take? What parts of netanim presently lack much documentation?

			Planning also to extend the existing ns-3 tutorial with netanim examples would also be a worthwhile part of a project plan.

			'''4) Enhancements'''

			Applicant can propose to work on some of the above suggested enhancements (like conversion from XML to JSON format). Explain how Netanim might support parsing of JSON-formatted traces.

	* ''Required Experience:''C++		* ''Required Experience:''C++

Tomh: /* SCE codepoint for ns-3 TCP and Queue Disciplines */

2020-03-14T15:57:11Z

SCE codepoint for ns-3 TCP and Queue Disciplines

← Older revision		Revision as of 15:57, 14 March 2020
Line 208:		Line 208:
	** [https://datatracker.ietf.org/meeting/interim-2020-tsvwg-01/materials/slides-interim-2020-tsvwg-01-sessa-l4s-ce-ambiguity-issues.pdf IETF issues list]		** [https://datatracker.ietf.org/meeting/interim-2020-tsvwg-01/materials/slides-interim-2020-tsvwg-01-sessa-l4s-ce-ambiguity-issues.pdf IETF issues list]
	** [https://datatracker.ietf.org/meeting/interim-2020-tsvwg-01/materials/slides-interim-2020-tsvwg-01-sessa-some-congestion-experienced.pdf Recent SCE presentation]		** [https://datatracker.ietf.org/meeting/interim-2020-tsvwg-01/materials/slides-interim-2020-tsvwg-01-sessa-some-congestion-experienced.pdf Recent SCE presentation]
			** [https://tools.ietf.org/html/draft-morton-tsvwg-codel-approx-fair-01 CNQ-CoDelAF]
			** [https://tools.ietf.org/html/draft-morton-tsvwg-lightweight-fair-queueing-00 Lightweight FQ]

	==== Cheap Nasty Queuing (CNQ) and Lightweight Fair Queuing (LFQ) models for ns-3 ====		==== Cheap Nasty Queuing (CNQ) and Lightweight Fair Queuing (LFQ) models for ns-3 ====

Tomh: /* SCE codepoint for ns-3 TCP and Queue Disciplines */

2020-03-14T15:52:55Z

SCE codepoint for ns-3 TCP and Queue Disciplines

← Older revision		Revision as of 15:52, 14 March 2020
Line 206:		Line 206:
	** [https://github.com/chromi/sce/commits/sce Linux implementation of SCE]		** [https://github.com/chromi/sce/commits/sce Linux implementation of SCE]
	** [https://www.nsnam.org/docs/models/html/tcp.html#support-for-explicit-congestion-notification-ecn ECN implementation in ns-3]		** [https://www.nsnam.org/docs/models/html/tcp.html#support-for-explicit-congestion-notification-ecn ECN implementation in ns-3]
			** [https://datatracker.ietf.org/meeting/interim-2020-tsvwg-01/materials/slides-interim-2020-tsvwg-01-sessa-l4s-ce-ambiguity-issues.pdf IETF issues list]
			** [https://datatracker.ietf.org/meeting/interim-2020-tsvwg-01/materials/slides-interim-2020-tsvwg-01-sessa-some-congestion-experienced.pdf Recent SCE presentation]

	==== Cheap Nasty Queuing (CNQ) and Lightweight Fair Queuing (LFQ) models for ns-3 ====		==== Cheap Nasty Queuing (CNQ) and Lightweight Fair Queuing (LFQ) models for ns-3 ====

Tomh: /* Usability improvements */

2020-03-06T22:41:40Z

Usability improvements

← Older revision		Revision as of 22:41, 6 March 2020
Line 113:		Line 113:
	* How to integrate a more Python-centric data flow and tools, such as [http://jupyter.org/ Jupyter Notebook] and [https://github.com/bloomberg/bqplot bqplot]		* How to integrate a more Python-centric data flow and tools, such as [http://jupyter.org/ Jupyter Notebook] and [https://github.com/bloomberg/bqplot bqplot]
	* Internal state visualization of Wi-Fi or LTE, such as the kind of plots generated by [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.126.3791&rep=rep1&type=pdf Yavista]		* Internal state visualization of Wi-Fi or LTE, such as the kind of plots generated by [http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.126.3791&rep=rep1&type=pdf Yavista]

			Students interested in usability, data visualization, and Python should have a close look at the next project idea from Davide Magrin!

	==== Improving SEM, a Simulation Execution Manager for ns-3 ====		==== Improving SEM, a Simulation Execution Manager for ns-3 ====