[Ns-developers] [nsc/ns3] status and plans

[Sam Jansen]

2008/7/10 Mathieu Lacage <mathieu.lacage at sophia.inria.fr>:

> hi florian,
>
> After trying to use the nsc/ns-3 trees for the attribute stuff, I have
> to confess that I am really scared about the whole user experience, and
> I think that there are a few things which really need to be addressed
> before trying to keep working on the linux 2.6.26 code.
>

I'll let Florian answer some more of this, but...


>
> 1) nsc must be separately downloaded, built, installed (with a couple of
> magic ln commands), and, then, we can build the nsc-ns-3 code. It would
> be _really_ helpful if you could make this whole process automatic
> within ns-3. Since sam finally moved to a mercurial repo for nsc, you
> should be able to use a strategy similar to the one used for the
> reference traces and download automatically with mercurial (or a tarball
> with wget) the nsc tree when it is needed (the user does not specify
> --disable-nsc). Ideally, the ns-3 build system would also be able to
> invoke the nsc build system (scons), and, then, install nsc correctly to
> make ns-3 find it. Sam mentionned that he considered using waf instead
> of scons but got scared by the lack of documentation. I would suggest
> that you try to bring gustavo in the loop to figure out if he can help
> with that and, if he can't what he can do to help you make ns-3 figure
> things out for nsc.
>

We're considering moving to waf to make the integration better and to remove
a dependency.

I'm also fixing up the problems with needing special versions of gcc and the
like; I think this is mostly done, but not pushed to the tree yet
(need to do a bit more testing yet).


>
> 2) Obviously, nsc does not work on 64bit systems: trying to build the
> nsc code as 32bit code on a 64bit system has proven to be a serious
> challenge. Sam is aware of that issue and plans to fix this by making
> the code build natively to 64bit on 64bit systems so, we are on the
> right track but, I think that this issue is really important to make it
> easier to get started with nsc/ns-3 so, we need to keep track of it and
> make sure that we scream at sam if he does not get to do it himself.
>

I'm working on this.

Actually, I got the Linux 2.6.18 stack running in 64-bit mode last night. It
needs a small amount of work to be tidied up, and some amount of validation,
but it ran our normal testcase fine. The other Linux versions will follow
very shortly.

So I'm hoping over the next week or two I'll get all the stacks to the stage
where they can be built and run in a 64-bit environment.


>
> 3) I see that your focus lately has been to try to bring in more
> protocols from newer kernels to work within nsc. This is great but it
> would be nice if we could figure out what is really the priority before
> merging your code in ns-3. I can see a couple of other (maybe not
> equally important) items so, here is a small list which I would like to
> discuss (feel free to add more to it):
>  a) add netlink sockets
>  b) make nsc use the native ipv4/arp stacks and ignore the ns-3
> ipv4/arp stacks.
>  c) bring in ipv6
> It is clear to me that c) is not possible until the other ns-3 ipv6 code
> has made progress so, let's ignore it. I am not sure what a) would be
> really useful for so, we could ignore it. b) might be potentially much
> more interesting but might be too much work within the scope of a gsoc
> project.
>
> Neither 1 nor 2 are highly complex technical problems and I understand
> that they could be seen as being a bit boring :) Both, are, however,
> critical to make it possible to deploy nsc as largely as possible so, it
> would be really nice if you could try to spend some time on any of these
> issues before proceeding further with more kernel code or, if you really
> want to keep working on kernel code, that you set a date after which,
> whether the kernel code is done or not, you will work on these build
> issues.
>
> regards,
> Mathieu
>
>