GSOC2015Projects - Revision history

Tomh: update link

2015-03-16T16:49:25Z

update link

← Older revision		Revision as of 16:49, 16 March 2015
Line 7:		Line 7:
	* [[GSOCMentorGuide \| ns-3's GSoC Mentor guide]]		* [[GSOCMentorGuide \| ns-3's GSoC Mentor guide]]
	* [[GSOCSelectionProcess \| GSoC Student Selection Process]]		* [[GSOCSelectionProcess \| GSoC Student Selection Process]]
	* [[~~GSOC2014PatchRequirement~~ \| Patch Requirement Guidelines ~~(from 2014)~~ ]]		* [[GSOC2015PatchRequirement \| Patch Requirement Guidelines]]
	* [[GSOC2015StudentApplicationTemplate \|GSoC Student application template]]		* [[GSOC2015StudentApplicationTemplate \|GSoC Student application template]]
	* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] \| ''IRC'' #ns-3 on freenode.net		* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] \| ''IRC'' #ns-3 on freenode.net

Tomh: update link

2015-03-16T00:26:41Z

update link

← Older revision		Revision as of 00:26, 16 March 2015
Line 8:		Line 8:
	* [[GSOCSelectionProcess \| GSoC Student Selection Process]]		* [[GSOCSelectionProcess \| GSoC Student Selection Process]]
	* [[GSOC2014PatchRequirement \| Patch Requirement Guidelines (from 2014) ]]		* [[GSOC2014PatchRequirement \| Patch Requirement Guidelines (from 2014) ]]
	* [[~~GSOC2014StudentApplicationTemplate~~ \|GSoC Student application template ~~(from 2014)~~]]		* [[GSOC2015StudentApplicationTemplate \|GSoC Student application template]]
	* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] \| ''IRC'' #ns-3 on freenode.net		* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] \| ''IRC'' #ns-3 on freenode.net

Tommaso: /* ARP and NDisc cache visibility and neighbor table changes */

2015-03-11T19:20:40Z

ARP and NDisc cache visibility and neighbor table changes

← Older revision		Revision as of 19:20, 11 March 2015
Line 88:		Line 88:
	Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]		Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]

	There is no user-friendly API for reading and manipulating the IPv4 ARP and IPv6 Neighbor Discovery caches. ~~Something similar to how PrintRoutes is done for~~ IPv4 ~~would~~ be ~~useful to print out~~ the ~~contents of the cache~~. ~~However, some~~ simulations may want to disable ARP and start with pre-populated ARP tables (because the ARP request/reply introduces a latency that is not desired in the program). There is presently no way to add static neighbor table entries; all added entries will timeout unless refreshed. There is a way to manually inject dynamic table entries to the ArpCache, if one can obtain a pointer to this object.		There is no user-friendly API for reading and manipulating the IPv4 ARP and IPv6 Neighbor Discovery caches. IPv4 and IPv6 neighbor caches can be printed, but the interactions is still very limited. Some simulations may want to disable ARP and start with pre-populated ARP tables (because the ARP request/reply introduces a latency that is not desired in the program). Moreover, some protocols (e.g., 6LoWPAN-ND) may need to modify radically how the caches are accessed and populated.
			There is presently no way to add static neighbor table entries; all added entries will timeout unless refreshed. There is a way to manually inject dynamic table entries to the ArpCache, if one can obtain a pointer to this object, but this is cumbersome.
			Finally, there are some neighbor caches improvements to be considered, e.g., the ones described in [https://www.nsnam.org/bugzilla/show_bug.cgi?id=2057 Bug 2057: ARP and NDisc caches should be updated by L4].

	A good application for this type of project would be to list some desired functional requirements from a usability perspective, and describe (perhaps by sketching out some sample API) how the functions would be provided by ns-3. For instance, is a new helper object needed, or can existing helper objects be extended? A good application would also outline how real systems access and manipulate the ARP and neighbor discovery caches, and draw parallels between the tools in use on a real system (such as the 'iproute2' program) and how the ns-3 API would be designed. Additional work on this project could focus on IP address handling for interfaces (bugs 757 and 760), and bug 187 (enabling perfect ARP). Another related bug is [https://www.nsnam.org/bugzilla/show_bug.cgi?id=652 Bug 652].		A good application for this type of project would be to list some desired functional requirements from a usability perspective, and describe (perhaps by sketching out some sample API) how the functions would be provided by ns-3. For instance, is a new helper object needed, or can existing helper objects be extended? A good application would also outline how real systems access and manipulate the ARP and neighbor discovery caches, and draw parallels between the tools in use on a real system (such as the 'iproute2' program) and how the ns-3 API would be designed. Additional work on this project could focus on IP address handling for interfaces (bugs 757 and 760), and bug 187 (enabling perfect ARP). Another related bug is [https://www.nsnam.org/bugzilla/show_bug.cgi?id=652 Bug 652].

Tomh: /* ARP and NDisc cache visibility and neighbor table changes */

2015-03-10T16:45:00Z

ARP and NDisc cache visibility and neighbor table changes

← Older revision		Revision as of 16:45, 10 March 2015
Line 88:		Line 88:
	Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]		Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]

	* There is no API for reading and manipulating the IPv4 ARP and IPv6 Neighbor Discovery caches. Something similar to how PrintRoutes is done for IPv4 would be useful. There is no way to ~~manually~~ add ~~or delete~~ neighbor table entries. Additional work on this project could focus on IP address handling for interfaces (bugs 757 and 760), and bug 187 (enabling perfect ARP). Another related bug is [https://www.nsnam.org/bugzilla/show_bug.cgi?id=652 Bug 652].		There is no user-friendly API for reading and manipulating the IPv4 ARP and IPv6 Neighbor Discovery caches. Something similar to how PrintRoutes is done for IPv4 would be useful to print out the contents of the cache. However, some simulations may want to disable ARP and start with pre-populated ARP tables (because the ARP request/reply introduces a latency that is not desired in the program). There is presently no way to add static neighbor table entries; all added entries will timeout unless refreshed. There is a way to manually inject dynamic table entries to the ArpCache, if one can obtain a pointer to this object.

			A good application for this type of project would be to list some desired functional requirements from a usability perspective, and describe (perhaps by sketching out some sample API) how the functions would be provided by ns-3. For instance, is a new helper object needed, or can existing helper objects be extended? A good application would also outline how real systems access and manipulate the ARP and neighbor discovery caches, and draw parallels between the tools in use on a real system (such as the 'iproute2' program) and how the ns-3 API would be designed. Additional work on this project could focus on IP address handling for interfaces (bugs 757 and 760), and bug 187 (enabling perfect ARP). Another related bug is [https://www.nsnam.org/bugzilla/show_bug.cgi?id=652 Bug 652].
	* ''Required Experience:'' C++		* ''Required Experience:'' C++
	* ''Interests:'' IPv4 and Ipv6		* ''Interests:'' IPv4 and Ipv6
Line 95:		Line 97:
	** source code in src/internet, and the bugs mentioned above		** source code in src/internet, and the bugs mentioned above
	** the Linux iproute2 tool		** the Linux iproute2 tool
	* ''Design suggestion:'' An iproute2 helper. The basic idea is to create a string parser that could parse strings that one would commonly issue on a ~~box~~ that supports iproute2. If presented with a string that was unsupported, it would ~~exit (FATAL_ERROR_MSG) but print out a message asking for the user~~ to ~~submit~~ a ~~patch to add support~~ for ~~the invalid string.~~ Example API:		* ''Design suggestion:'' An iproute2 helper could be created to support strings that are commonly passed to the iproute2 tool on a real system. The basic idea is to create a string parser that could parse strings that one would commonly issue on a system that supports iproute2. If presented with a string that was unsupported, it would have to handle this some way-- what would be a good suggestion for handling this case?
			Example API:
	<pre>		<pre>
	Iproute2Helper i;		Iproute2Helper i;
Line 110:		Line 113:
	bool ok = i.Cmd (n, "ip neighbor add 192.168.99.254 lladdr 00:80:c8:27:69:2d dev eth3");		bool ok = i.Cmd (n, "ip neighbor add 192.168.99.254 lladdr 00:80:c8:27:69:2d dev eth3");
	</pre>		</pre>
	Doing this would require some additional work in assigning human-friendly names like eth0 to interfaces.		Doing this would require some additional work in assigning human-friendly names like eth0 to interfaces.

	==== Inter-frequency measurement support for the LTE module ====		==== Inter-frequency measurement support for the LTE module ====

Tomh: /* Decouple traffic generators from sockets */

2015-03-09T19:49:00Z

Decouple traffic generators from sockets

← Older revision		Revision as of 19:49, 9 March 2015
Line 71:		Line 71:
	Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]		Mentors: [mailto:tomh@tomh.org Tom Henderson] [mailto:rivanvx@gmail.com Vedran Miletić]

	* ns-3 uses applications that are part traffic generator, part socket-based application. The traffic generation part is not decoupled from the sockets API, making it hard to use applications over non-socket APIs such as future sensor networks. This project would work on a cleaner separation between traffic generator (OnOffApplication) and sockets.		* ns-3 uses applications that are part traffic generator, part socket-based application. The traffic generation part is not decoupled from the sockets API, making it hard to use applications over non-socket APIs such as future sensor networks. This project would work on a cleaner separation between traffic generator (OnOffApplication) and sockets. This is not necessarily restricted to OnOffApplication; maybe the new generator is something like MGEN: http://www.nrl.navy.mil/itd/ncs/products/mgen

			Here is an example problem to consider answering in your application. How would you change the [https://codereview.appspot.com/4997043/ proposed Poisson Pareto Burst Process] code to make it run either over IP sockets or over a NetDevice model?

	* ''Required Experience:'' C++, sockets API		* ''Required Experience:'' C++, sockets API
	* ''Interests:''		* ''Interests:''

Tomh: /* TCP validation */

2015-03-09T19:39:51Z

TCP validation

← Older revision		Revision as of 19:39, 9 March 2015
Line 230:		Line 230:
	Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]		Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]

	TCP is one of the most widely used and widely studied protocols in the Internet. ns-3 has a number of TCP (congestion control) variants. Recently, RFC 5681 was published, documenting recommended TCP behavior. This project would consist of reviewing the ns-3 TCP implementations and testing them for conformance to RFC 5681 (and fixing any issues that were found to arise). One outcome of this project would be a test suite that will ensure that ns-3's TCP implementation is accurate and does not regress over time. We also have some new TCP variants coming available in ns-3 (Cubic, SACK, Compound) that need testing.		This project concerns the verification (checking that TCP is correctly implemented) and validation (checking that TCP models provide results similar to those of real systems) of ns-3 native TCP models. TCP is one of the most widely used and widely studied protocols in the Internet. ns-3 has a number of TCP (congestion control) variants. Recently, RFC 5681 was published, documenting recommended TCP behavior. This project would consist of reviewing the ns-3 TCP implementations and testing them for conformance to RFC 5681 (and fixing any issues that were found to arise). One outcome of this project would be a test suite that will ensure that ns-3's TCP implementation is accurate and does not regress over time. We also have some new TCP variants coming available in ns-3 (Cubic, SACK, Compound) that need testing.

	Are you interested in this project? In your application, please tell us how you plan to test ns-3 TCP. Be as specific as possible, to convey that you know enough about ns-3 to make good progress. Tell us how you would create conditions (packet losses, reordering) to test TCP. What strategies can you use to test ns-3 TCP against a real implementation? How are you going to specifically verify that a value for a TCP state variable is the proper value at the right time? The most successful application would actually write a few working TCP tests (that run in the ns-3 regression test suite) and point us to the code (perhaps on github or some other site), and would go on to outline what additional tests would be prioritized in the GSoC program.		Are you interested in this project? In your application, please tell us how you plan to test ns-3 TCP. Be as specific as possible, to convey that you know enough about ns-3 to make good progress. Tell us how you would create conditions (packet losses, reordering) to test TCP. What strategies can you use to test ns-3 TCP against a real implementation? How are you going to specifically verify that a value for a TCP state variable is the proper value at the right time? The most successful application would actually write a few working TCP tests (that run in the ns-3 regression test suite) and point us to the code (perhaps on github or some other site), and would go on to outline what additional tests would be prioritized in the GSoC program.

Tomh: add Tmix/delaybox project

2015-03-09T13:13:15Z

add Tmix/delaybox project

← Older revision		Revision as of 13:13, 9 March 2015
Line 252:		Line 252:
	Mentor: [mailto:tomh@tomh.org Tom Henderson]		Mentor: [mailto:tomh@tomh.org Tom Henderson]

	* '''Modular build system.''' This is a project that requires no networking experience, and is for students with Python skills who are interested in build systems. ns-3 is in the midst of a transition to a [[BakeIntegration \| modular build system]], managed by a tool called [http://www-sop.inria.fr/members/Daniel.Camara/bake/ bake] that is similar to GNOME JHBuild or other dependency managers. A student for this project would work on a daily basis with Tom Henderson (who is already working on this project) to perform tasks such as the following: 1) Port bake to Python 3, 2) Ensure that bake is documented so that automated tools can build API documentation, 3) Test bake on a number of platforms, 4) allow for wildcard expressions in bake dependencies, 5) consider configuration file move from XML to JSON, 6) convert our Doxygen and Sphinx infrastructure to operate on a per-module basis, 7) consider whether Linux package manager database formats and tools can be reused to manage ns-3 package dependencies, 8) help us write a manual for bake, etc. The interested student is encouraged to start discussing possible application preparation with Tom prior to the application deadline. A good grasp of Python and how Linux systems (libraries, package managers) are organized is essential. Because this is intended to be cross-platform, experience with other systems (FreeBSD, OS X, Windows) would also be a plus.		This is a project that requires no networking experience, and is for students with Python skills who are interested in build systems. ns-3 is in the midst of a transition to a [[BakeIntegration \| modular build system]], managed by a tool called [http://www-sop.inria.fr/members/Daniel.Camara/bake/ bake] that is similar to GNOME JHBuild or other dependency managers. A student for this project would work on a daily basis with Tom Henderson (who is already working on this project) to perform tasks such as the following: 1) Port bake to Python 3, 2) Ensure that bake is documented so that automated tools can build API documentation, 3) Test bake on a number of platforms, 4) allow for wildcard expressions in bake dependencies, 5) consider configuration file move from XML to JSON, 6) convert our Doxygen and Sphinx infrastructure to operate on a per-module basis, 7) consider whether Linux package manager database formats and tools can be reused to manage ns-3 package dependencies, 8) help us write a manual for bake, etc. The interested student is encouraged to start discussing possible application preparation with Tom prior to the application deadline. A good grasp of Python and how Linux systems (libraries, package managers) are organized is essential. Because this is intended to be cross-platform, experience with other systems (FreeBSD, OS X, Windows) would also be a plus.
	** ''Required Experience:'' Python, Linux systems		* ''Required Experience:'' Python, Linux systems
	** ''Bonus Experience:'' FreeBSD, OS X, Windows Visual Studio		* ''Bonus Experience:'' FreeBSD, OS X, Windows Visual Studio
	** ''Interests:'' Build systems		* ''Interests:'' Build systems
	** ''Difficulty:'' depends on student's Python and Linux proficiency, can range from easy to difficult		* ''Difficulty:'' depends on student's Python and Linux proficiency, can range from easy to difficult

			==== TMix and DelayBox integration ====

			Mentor: [mailto: tomh@tomh.org Tom Henderson]

			[http://www.isi.edu/nsnam/ns/doc/node563.html Tmix] is a popular ns-2 utility for generating synthetic TCP traffic load. [http://www.isi.edu/nsnam/ns/doc/node247.html#chap:delaybox DelayBox] is another ns-2 testing tool, part of TMix; DelayBox allows to introduce per-flow delay and loss on the traffic streams. Some initial ports of these capabilities are found at a [https://code.google.com/p/tmix-ns3/ Google code site]. In this project, we want to finish these off (test, documentation, example scripts) and make more broadly available as part of ns-3 releases.

			DelayBox is presently implemented as a standalone node in the network (it is literally a node into which packets are sent, and the packets emerge on another link after going through loss and delay modules). A successful application to this project will look at the existing DelayBox code and sketch out how it could instead be supported as a plugin on a network interface card (ns3::NetDevice model), without introducing a new node in the simulation topology (hint: see how error models are handled by ns-3 NetDevices). This would then be similar to the [http://www.linuxfoundation.org/collaborate/workgroups/networking/netem Linux netem] capability or [http://www.freebsd.org/cgi/man.cgi?format=html&query=dummynet%284%29 FreeBSD dummynet] capability. This begs the question; could the ns-3 DelayBox model, instantiated on a ns3::NetDevice, be configured by an API that resembles the netem or dummynet configuration commands?

			The successful application to this project will also tell us what additional traffic models he or she might work on once Tmix and DelayBox are finished. Finish up and test the [http://mailman.isi.edu/pipermail/ns-developers/2011-September/009427.html Poisson Pareto Burst Process] traffic model? Something else that interests you?

			* ''Required Experience:'' some TCP background, knowledge of FreeBSD dummynet or Linux netem tools
			* ''Interests:'' Internet traffic models, testing of network simulation scenarios
			* ''Difficulty:'' easy to medium

	[[Category:GSoC]]		[[Category:GSoC]]

Tomh: /* TCP validation */

2015-03-09T12:51:44Z

TCP validation

← Older revision		Revision as of 12:51, 9 March 2015
Line 230:		Line 230:
	Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]		Mentors: [mailto:tomh@tomh.org Tom Henderson], [mailto:tommaso.pecorella@unifi.it Tommaso Pecorella]

	* '''TCP Validation.''' TCP is one of the most widely used and widely studied protocols in the Internet. ns-3 has a number of TCP (congestion control) variants. Recently, RFC 5681 was published, documenting recommended TCP behavior. This project would consist of reviewing the ns-3 TCP implementations and testing them for conformance to RFC 5681 (and fixing any issues that were found to arise). One outcome of this project would be a test suite that will ensure that ns-3's TCP implementation is accurate and does not regress over time. We also have some new TCP variants coming available in ns-3 (Cubic, SACK, Compound) that need testing.		TCP is one of the most widely used and widely studied protocols in the Internet. ns-3 has a number of TCP (congestion control) variants. Recently, RFC 5681 was published, documenting recommended TCP behavior. This project would consist of reviewing the ns-3 TCP implementations and testing them for conformance to RFC 5681 (and fixing any issues that were found to arise). One outcome of this project would be a test suite that will ensure that ns-3's TCP implementation is accurate and does not regress over time. We also have some new TCP variants coming available in ns-3 (Cubic, SACK, Compound) that need testing.
	** ''Required Experience:'' C++
	** ''Bonus Experience:'' Transport protocols or TCP		Are you interested in this project? In your application, please tell us how you plan to test ns-3 TCP. Be as specific as possible, to convey that you know enough about ns-3 to make good progress. Tell us how you would create conditions (packet losses, reordering) to test TCP. What strategies can you use to test ns-3 TCP against a real implementation? How are you going to specifically verify that a value for a TCP state variable is the proper value at the right time? The most successful application would actually write a few working TCP tests (that run in the ns-3 regression test suite) and point us to the code (perhaps on github or some other site), and would go on to outline what additional tests would be prioritized in the GSoC program.
	** ''Interests:'' TCP and transport protocol performance
	** ''Difficulty:'' depends on what functionality the student proposes to implement		* ''Required Experience:'' C++
	** ''Background mail message:'' http://mailman.isi.edu/pipermail/ns-developers/2010-March/007593.html		* ''Bonus Experience:'' Transport protocols or TCP
	** ''TCP background references:''		* ''Interests:'' TCP and transport protocol performance
	*** [http://www.ietf.org/rfc/rfc793.txt RFC 793] (the original TCP specification)		* ''Difficulty:'' depends on what functionality the student proposes to implement
	*** [http://www.ietf.org/rfc/rfc4614.txt RFC 4614] (TCP roadmap)		* ''Background mail message:'' http://mailman.isi.edu/pipermail/ns-developers/2010-March/007593.html
	*** [http://www.ietf.org/rfc/rfc5681.txt RFC 5681] (TCP congestion control)		* ''TCP background references:''
	*** [http://www.informit.com/store/tcp-ip-illustrated-volume-1-the-protocols-9780321336316 TCP/IP Illustrated, volume 1]		** [http://www.ietf.org/rfc/rfc793.txt RFC 793] (the original TCP specification)
	** ''TCP testing references:''		** [http://www.ietf.org/rfc/rfc4614.txt RFC 4614] (TCP roadmap)
	*** [http://researchcommons.waikato.ac.nz/handle/10289/3287 Sam Jansen's thesis] (see in particular chapters 4 and 5)		** [http://www.ietf.org/rfc/rfc5681.txt RFC 5681] (TCP congestion control)
	*** [http://ssfnet.org/Exchange/tcp/tcpTestPage.html SSFNet TCP tests]		** [http://www.informit.com/store/tcp-ip-illustrated-volume-1-the-protocols-9780321336316 TCP/IP Illustrated, volume 1]
			* ''TCP testing references:''
			** [http://researchcommons.waikato.ac.nz/handle/10289/3287 Sam Jansen's thesis] (see in particular chapters 4 and 5)
			** [http://ssfnet.org/Exchange/tcp/tcpTestPage.html SSFNet TCP tests]

	==== Modular build system ====		==== Modular build system ====

Tomh: fix broken link

2015-03-09T12:40:34Z

fix broken link

← Older revision		Revision as of 12:40, 9 March 2015
Line 239:		Line 239:
	*** [http://www.ietf.org/rfc/rfc793.txt RFC 793] (the original TCP specification)		*** [http://www.ietf.org/rfc/rfc793.txt RFC 793] (the original TCP specification)
	*** [http://www.ietf.org/rfc/rfc4614.txt RFC 4614] (TCP roadmap)		*** [http://www.ietf.org/rfc/rfc4614.txt RFC 4614] (TCP roadmap)
	*** [http://www.ietf.org/rfc/~~rfc4614~~.txt RFC 5681] (TCP congestion control)		*** [http://www.ietf.org/rfc/rfc5681.txt RFC 5681] (TCP congestion control)
	*** [http://www.informit.com/store/tcp-ip-illustrated-volume-1-the-protocols-9780321336316 TCP/IP Illustrated, volume 1]		*** [http://www.informit.com/store/tcp-ip-illustrated-volume-1-the-protocols-9780321336316 TCP/IP Illustrated, volume 1]
	** ''TCP testing references:''		** ''TCP testing references:''

Tomh: /* TCP validation */

2015-03-08T15:59:38Z

TCP validation

← Older revision		Revision as of 15:59, 8 March 2015
Line 242:		Line 242:
	*** [http://www.informit.com/store/tcp-ip-illustrated-volume-1-the-protocols-9780321336316 TCP/IP Illustrated, volume 1]		*** [http://www.informit.com/store/tcp-ip-illustrated-volume-1-the-protocols-9780321336316 TCP/IP Illustrated, volume 1]
	** ''TCP testing references:''		** ''TCP testing references:''
	*** [http://researchcommons.waikato.ac.nz/handle/10289/3287 Sam Jansen's thesis] (see in particular ~~chapter~~ 5)		*** [http://researchcommons.waikato.ac.nz/handle/10289/3287 Sam Jansen's thesis] (see in particular chapters 4 and 5)
	*** [http://ssfnet.org/Exchange/tcp/tcpTestPage.html SSFNet TCP tests]		*** [http://ssfnet.org/Exchange/tcp/tcpTestPage.html SSFNet TCP tests]

← Older revision		Revision as of 16:49, 16 March 2015
Line 7:		Line 7:
	* [[GSOCMentorGuide \| ns-3's GSoC Mentor guide]]		* [[GSOCMentorGuide \| ns-3's GSoC Mentor guide]]
	* [[GSOCSelectionProcess \| GSoC Student Selection Process]]		* [[GSOCSelectionProcess \| GSoC Student Selection Process]]
	* [[~~GSOC2014PatchRequirement~~ \| Patch Requirement Guidelines ~~(from 2014)~~ ]]		* [[GSOC2015PatchRequirement \| Patch Requirement Guidelines]]
	* [[GSOC2015StudentApplicationTemplate \|GSoC Student application template]]		* [[GSOC2015StudentApplicationTemplate \|GSoC Student application template]]
	* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] \| ''IRC'' #ns-3 on freenode.net		* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] \| ''IRC'' #ns-3 on freenode.net

← Older revision		Revision as of 00:26, 16 March 2015
Line 8:		Line 8:
	* [[GSOCSelectionProcess \| GSoC Student Selection Process]]		* [[GSOCSelectionProcess \| GSoC Student Selection Process]]
	* [[GSOC2014PatchRequirement \| Patch Requirement Guidelines (from 2014) ]]		* [[GSOC2014PatchRequirement \| Patch Requirement Guidelines (from 2014) ]]
	* [[~~GSOC2014StudentApplicationTemplate~~ \|GSoC Student application template ~~(from 2014)~~]]		* [[GSOC2015StudentApplicationTemplate \|GSoC Student application template]]
	* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] \| ''IRC'' #ns-3 on freenode.net		* ''Get in contact with the ns-3 team'': [http://mailman.isi.edu/mailman/listinfo/ns-developers ns-developers mailing list] \| ''IRC'' #ns-3 on freenode.net