GSOC2015MpTcpImplementation - Revision history

Pdbarnes: /* On the per node clock */ Link to Local Clocks page

2019-02-01T18:37:30Z

On the per node clock: Link to Local Clocks page

← Older revision		Revision as of 18:37, 1 February 2019
Line 60:		Line 60:
	I would like to start implementing per node clock to be able to simulate time distribution protocols. Right now nodes are all perfectly synchronized ins ns3 (they share the simulator clocks). My goal is to be able to run NTPD in ns3-dce over ns3 nodes with drifting clocks. Time distribution experimentations are hard to do in practice (do you control 2 or more stratum 1 NTP servers ? and the traffic between these), I believe it makes sens and I know of no simulator that does it. This proposition is a follow up of my email to the dev ml: http://network-simulator-ns-2.7690.n7.nabble.com/Addition-of-per-node-clocks-in-ns3-td29301.html		I would like to start implementing per node clock to be able to simulate time distribution protocols. Right now nodes are all perfectly synchronized ins ns3 (they share the simulator clocks). My goal is to be able to run NTPD in ns3-dce over ns3 nodes with drifting clocks. Time distribution experimentations are hard to do in practice (do you control 2 or more stratum 1 NTP servers ? and the traffic between these), I believe it makes sens and I know of no simulator that does it. This proposition is a follow up of my email to the dev ml: http://network-simulator-ns-2.7690.n7.nabble.com/Addition-of-per-node-clocks-in-ns3-td29301.html

			More discussion of this topic is on the [[Local Clocks]] page.

	= Expected deliverables =		= Expected deliverables =

Teto: /* Final review */

2015-08-25T14:07:03Z

Final review

← Older revision		Revision as of 14:07, 25 August 2015
Line 433:		Line 433:

	== Final review ==		== Final review ==
	~~Not~~ quite there yet.
			This is my final report for the Gsoc 2015 on Clock support & MpTcp
			Implementation on Linux.

			I will sum up the work done and some propositions for the after Gsoc.
			- During the first half of my Gsoc, I have been working on allowing
			each node to run its own clock [0]. This way each node can have its
			own time. It makes sense to test the difference in behavior of
			protocols that depend on node synchronization. The clock takes some
			parameters such as the raw frequency which can change over time. In
			the end every event must be queued into the main simulator class. To
			prevent the addition/update (when clock parameters change)/removal of
			events, we only queue the next node event in the global Simulator.
			Thus if the node clock change, it's enough to reschedule the event.
			Once the event is fired, we schedule the next node event.
			During this process, I also was able to run an unmodified ntpd (the
			Nework Time Protocol daemon) in DCE with specific DCE patches [1].

			- As for the Mptcp implementation, I got a much cleaner version then
			the initial one. There is now a clear difference between the "meta
			socket" (seen by the applications) and the TCP subflows (traditional
			TCP connections). The old meta was sending packets etc... while now it
			focuses on the logic between subflows. Also it used to be a modified
			copy/paste of TcpSocketBase while now subflows and meta integrate with
			it, resulting in less code duplication. I've also improved the
			TCP/MPTCP compatiblity, i.e., MPTCP is now a TCP option like any other
			while you used to create a specific MPTCP socket. For instance when
			you had one MPTCP socket connecting to a legacy TCP one, it was
			impossible before the Gsoc and now it is. [1] I managed to exchange a
			file between 2 nodes with 1 subflow. The multiple subflow case is
			trickier and while a second subflow can be established, I have to do
			more testing before assessing anything else.

			I've also sent a few patches to:
			- upgrade waf to 1.8 (with vedran's help mostly)
			- provided a script to allow YouCompleteMe (a vim completion engine)
			to work with ns3

			I don't think any of these 2 are ready for reviewing yet. Don't get me
			wrong, I have working tests in each case but each project is
			intertwined with other ns3 components (the TCP stack, DCE, event
			handling) and thus require specific attention to the API. I don't
			think I am quite there yet. Once I am I will clean/document the code
			and send official reviews. You can already have a look at it but the
			documentation may not be quite there yet.

Teto: /* Week 9 */

2015-08-23T23:32:22Z

Week 9

← Older revision		Revision as of 23:32, 23 August 2015
Line 338:		Line 338:

	== Week 9 ==		== Week 9 ==
			Hi,

			This week has been really tough in the sense I had to deal with 2
			problems in domains I was not very confident with. First I had to
			change the link order so that libgcrypt got linked first, which is not
			that simple if you are not familiar with waf. Many thanks to Alex
			Afanasyev who really saved me there. libgcrypt license is compatible
			with ns3. As discussed on the mailing list, it is an optional
			dependancy and it felt more natural than duplicating sha1 in ns3. This
			should allow to read mptcp pcap in wireshark, which relies on the
			token to identify subflows of a same connection.
			The second problem I had was dealing with the placement new. It seemed
			to create bugs in libc ("double linked list corrupted") and as I was
			unsure it was valid C++ I looked at the libc code just to realize that
			in fact I had left in the code a "CopyObject<TcpSocketBase>" that was
			not allocating enough memory to convert this TcpSocketBase to a
			MpTcpSocketBase.

			As for the TCP design, what I've done is to remove the
			TcpSocketBase::ReadOptions that was reading options even when the
			packet was discarded later on. I contextualize option reading as in
			linux with functions such as "ProcessTcpOptionsSynSent".
			I've also introduced a function
			"TcpSocketBase::IsTcpOptionEnabled(TcpOption::Kind)" which is easier
			to remember than the boolean for each option.


			As for next week, development should be a lot smoother:
			- Vedranm pushed the patch that was preventing me to propose DCE PRs.
			- I should be able to have a single subflow scenario running

			Cheers
			Matt

			[0] https://github.com/teto/ns-3-dev-git/tree/merge_nat

	== Week 10 ==		== Week 10 ==

Teto: /* Week 10 */

2015-08-23T23:31:48Z

Week 10

← Older revision		Revision as of 23:31, 23 August 2015
Line 346:		Line 346:
	adding a new function in the PcapHelper, I thought ns3 could bind the		adding a new function in the PcapHelper, I thought ns3 could bind the
	correct callback depending on the signature, something like if you		correct callback depending on the signature, something like if you
	can't bind to X, try Y etc... ~~So naively I wrote:~~		can't bind to X, try Y etc...

	By the way, I don't know why this function is a template since it is		By the way, I don't know why this function is a template since it is

Teto: /* = */

2015-08-23T23:31:35Z

← Older revision		Revision as of 23:31, 23 August 2015
Line 348:		Line 348:
	can't bind to X, try Y etc... So naively I wrote:		can't bind to X, try Y etc... So naively I wrote:

	~~===~~
	By the way, I don't know why this function is a template since it is		By the way, I don't know why this function is a template since it is
	equivalent to "void PcapHelper::HookDefaultSink (Ptr<Object> object,		equivalent to "void PcapHelper::HookDefaultSink (Ptr<Object> object,

Teto: /* = */

2015-08-23T23:31:21Z

@@ Line 348: / Line 348: @@
 can't bind to X, try Y etc... So naively I wrote:
 ===
 By the way, I don't know why this function is a template since it is

Teto: /* Week 10 */

2015-08-23T23:30:42Z

Week 10

@@ Line 340: / Line 340: @@
 == Week 10 ==
 == Final review ==
 Not quite there yet.

Teto: /* Weekly progress */

2015-07-27T10:35:15Z

Weekly progress

← Older revision		Revision as of 10:35, 27 July 2015
Line 335:		Line 335:

	[0] https://github.com/teto/ns-3-dev-git/tree/merge_nat		[0] https://github.com/teto/ns-3-dev-git/tree/merge_nat


			== Week 9 ==

			== Week 10 ==

	== Final review ==		== Final review ==
	Not quite there yet.		Not quite there yet.

Teto: /* Week 8 */

2015-07-27T09:57:10Z

Week 8

← Older revision		Revision as of 09:57, 27 July 2015
Line 315:		Line 315:
	Hi,		Hi,

	I've not been able to complete the tasks partly because I had less time to work		I've not been able to complete the tasks partly because I had less time to work due to personal issues and the tasks I had in mind required someinteractions. I spent time to investigate how to improve the MPTCP codebase.
	due to personal issues and the tasks I had in mind required ~~some~~		While the initial codebase copies a lot of code to minimize changes it makes it hard to maintain. Also the TCP changes made by Nat though interesting break how the initial MPTCP aware socket was created. Somehow this is a chance since it motivated me to look into MPTCP fallback. So far the user had to create an MPTCP socket and it would fail it the peer was not MPTCP compliant. I hope to minimize the
	~~interactions~~. I spent time to investigate how to improve the MPTCP		changes needed by the user to ease the use of MPTCP. This was not in the initial proposal and I've had a hard time defining an API but I believe we should do it as in the (linux) kernel:
	codebase.		-the client sends the MPTCP options during the SYN but does not
	While the initial codebase copies a lot of code to minimize changes
	it makes it hard to maintain. Also the TCP changes made by Nat though
	interesting break how the initial MPTCP aware socket was created.
	Somehow this is a chance since it motivated me to look into MPTCP
	fallback. So far the user had to create an MPTCP socket and it would
	fail it the peer was not MPTCP compliant. I hope to minimize the
	changes needed by the user to ease the use of MPTCP.
	This was not in the initial proposal and I've had a hard time
	defining an API but I believe we should do it as in the (linux)
	kernel:
	- the client sends the MPTCP options during the SYN but does not
	instantiate any MPTCP related structure		instantiate any MPTCP related structure
	- upon SYN/ACK, it generates MPTCP structures, copies the current		-upon SYN/ACK, it generates MPTCP structures, copies the current
	socket (the copy becomes the "master" socket) and uses the socket seen		socket (the copy becomes the "master" socket) and uses the socket seen
	by the application as the metasocket		by the application as the metasocket

	In the case of ns3, this approach is more problematic because of the		In the case of ns3, this approach is more problematic because of the Ptr<Socket> indirection. Thus I've used "placement new" to replace a TcpSocketBase instance with an MpTcpSocketBase. This is a bit tricky and this as far as I went.
	Ptr<Socket> indirection. Thus I've used "placement new" to replace a
	TcpSocketBase instance with an MpTcpSocketBase. This is a bit tricky
	and this as far as I went.


	So for next week to sum up, I have to:		So for next week to sum up, I have to:
	- address comments on time simulation		-address comments on time simulation
	- keep working on MPTCP		-keep working on MPTCP

	Cheers		Cheers

Teto: /* Week 8 */

2015-07-27T09:55:34Z

Week 8

@@ Line 313: / Line 313: @@
 == Week 8 ==
 == Final review ==
 Not quite there yet.