[Ns-developers] GSOC application requesting comments on proposals

Mathieu Lacage mathieu.lacage at sophia.inria.fr
Sun Mar 23 21:37:29 PDT 2008


hi ali,

On Sun, 2008-03-23 at 19:32 -0400, Ali Ahmed wrote:
> I have begun the initial process of building a proposal for integration of
> the linux  network stack in ns-3.
> 
> Here are some of my thoughts
> 
> One way to go about this is to target the latest version of linux kernel
> start form scratch and isolate the needed components via call tracing ,
> build the required abstraction layer to go onto ns-3 and glue them together
> 
> Something along the lines of thi
> http://www.irean.vt.edu/research_workshop_april2003/07_Knestrick.pdf
> 
> pros : Generates optimal result if the target is only the current Linux
> kernel
> 
> cons: Extremely Tedious process ( trial and error ) , multiple stack
> simulation will most likely come via fork() , whcih is no optimal .

Multiple stack simulation will come via so-called 'network namespaces'
which are a feature of the linux network stack which allows you to
associated a 'namespace' (aka, context) to the network stack which
represents the current 'container' context. More about this:
http://lxc.sourceforge.net/network.php

> 
> 
> Another way is to emulate Linux completely  say as in User Mode Linux or
> similar  virtualization systems
> 
> http://en.wikipedia.org/wiki/User-mode_Linux

None of the above will give you one of the most wanted user-visible
features of this project: the ability to run all the instances in a
single debugger. That solution would thus be highly suboptimal from the
point of view of the user.

> 
> pros : Multiple stack emulation is possible , possibly easier then the first
> solution
> 
> cons: unlikely process can replicated thorough all platforms . Quality of
> simulation will have answered questions.
> 
> 
> Yet another way is to follow the example of network simulation cradle which
> have already accomplished this for ns-2
> 
> pros : pre-established working code ,  known process etc., platform support.
> 
> cons : Integration can me messy (ns-3 api not complete) , not the most
> optimum way to get simulation for a say a specifically targeted stack , lack
> of fine grained control .

I could try to outline some of the technical issues which would make the
nsc solution suboptimal with regard to the final user-experience but the
final product would certainly be useful. I think that the main challenge
here is that there is a clear lack of description of the nsc project
goals, schedule, timeline, dynamics, and, more generally, a rather poor
grasp on what the future of this project will be.

I am sure that sam (who volunteered to help mentor a student working on
this project) will want to comment on the above paragraph, so, I CCed
him (his email might need an update but I don't know his new email so,
if someone knows his current email, please, forward this email to
him !).

So summarize, I think that of the 3 options you describe above, there
are really only 2 which would be useful and viable:
  1) target latest kernel, hand-made solution
  2) use nsc
  
Which of the two you will pick above will really depend on what you are
most interested in: in both cases, I believe that we will get some
useful code out.

best regards,
Mathieu



More information about the Ns-developers mailing list