[Ns-developers] Summer of Code nsc/ns-3 integration status, week 06

[Mathieu Lacage]

On Mon, 2008-06-02 at 17:29 +0200, Florian Westphal wrote:
> Hello everyone,
> 
> as explained in my last mail, the ns-3-nsc basics work.
> To allow run time usage of available nsc stacks, i've extended the
> InternetStackHelper:
> SetTcpType(std::string) allows to specify an nsc stack to use.
> I also added a second Install() method that gets a Node
> as the argument.

You do not need to do the latter because NodeContainer has a constructor
which takes a Ptr<Node> so, the following should work as-is:

helper.Install (container.Get (i));

because NodeContainer::Get returns a Ptr<Node> which is implicitely
converted to a NodeContainer object with a single node through the
NodeContainer::NodeContainer (Ptr<Node> node) constructor which is then
fed to InternetStackHelper::Install.

> A simulation can now e.g.:
> 
>    InternetStackHelper internet;
>    internet.SetTcpType("Linux");
>    internet.Install (c);
> 
> To tell ns-3 that NSCs Linux stack should be used.
> The InternetStackHelper maps the Name to the corresponding shared
> library. I'm not satisfied with this; I think that maybe it should
> get the actual shared library in the first place, because eventually
> there will probably a lot of "Linux" stacks, e.g. linux2618.so,
> linux2625.so, and so on. In any case, this is a minor detail and this
> can be adjusted as needed later on. In case SetTcpType() isn't called,
> the ns-3 tcp stack is used.

I see. That API is a bit confusing them because SetTcpType does more
than set the type of TCP implementation to use: it selects the "nsc" TCP
implementation, and within nsc, it selects an nsc stack using the nsc
dlopen mechanisms. So, I would expect something like this instead:

void InternetStackHelper::SetTcpDefault (void)
void InternetStackHelper::SetNscTcp (std::string subtype);

Which is not very different from what you have but the naming is, I
think, much clearer about the purpose.

There is another, more fancy and flexible, option which would, however,
be more complex to implement.

0) add src/node/tcp.h, virtual void Tcp::SetNode (Ptr<Node> node) = 0,
implement it in NscTcpSocketFactoryImpl::SetNode: instanciate
NscTcpL4Protocol there, aggregate it to node, register it with
Ipv4L4Demux. You would want to modify TcpSocketFactoryImpl also to do
the same thing and AddInternetStack to not create the L4Protocols
anymore.

1) add this API:
InternetStackHelper::SetTcp (std::string type, std::string name = "",
const AttributeValue &value = EmptyAttributeValue (), ...);
and implement it similar to WifiHelper::SetRemoteStationManager.

2) implement InternetStackHelper::Install:
for ()
  {
    Ptr<Node> n = ...;
    AddInternetStackArp (n);
    AddInternetStackIpv4 (n);
    Ptr<Tcp> tcp = m_tcpFactory.Create<Tcp> ();
    n->AggregateObject (tcp);
    tcp->SetNode (tcp);
  }
That would obviously require that you split the AddInternetStack
function but I had to do this already for bug 187 (not commited yet) so,
it will eventually be done.


> Open issues:
> - nsc-ipv4-l3-protocol.cc. This is exactly the same as
> ipv4-l3-protocol.cc, the only difference is that the nsc version
> doesn't remove the ip header before forwarding the packet to layer 4.
> I'll see about reconstructing the ipv4 header in the nsc-tcp-l4 class
> instead, this would make nsc-ipv4-l3-protocol obsolete.

sounds good.

> - code cleanup, there are still code redundancies in the nsc-socket and
> nsc-tcp-l4 classes. Will work on this.

ok.

> 
> Other open issues are the ns-3-nsc API, e.g. how should sysctls (e.g.
> for disabling SACK in Linux) and nsc setsockopts be exposed to the user?
> I will think about this and try to come forward with a few ideas this
> week. 

What would totally rock would be to allow sysctl to be exported as
Attributes which would allow us to control sysctl with normal
attributes, and, GtkConfigStore among others.

> I also plan to do some more tests with mixed setups (i.e.
> nsc-Linux <-> nsc-FreeBSD, etc.)

that sounds cool :)

Mathieu