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

[Florian Westphal]

Hi All,

Last week I changed the ns-3-nsc read-side glue to create packets and
put that into the application rx queue, just like the ns-3 tcp-socket
code.  Unfortunately, nsc has no API to retrieve the peer address,
so the packets don't have the the correct peer address tag.

This means that my work will now shift more to NSC itself, more
precisely I'd like to add getsockname and getpeername equivalents to
get the correct address endpoint information.

Also, I re-based the ns-3-nsc repository on top of current ns-3-dev.

The two major outstanding integration problems that I'm aware of are now
sysctl and setsockopt support.

I already talked to Mathieu about this (thanks again!), but let me first
illustrate how NSC currently exposes sysctls.

In NSC, a stack may implement the INetStack method
virtual int sysctl(const char *sysctl_name, void *oldval, size_t
		    *oldlenp, void *newval, size_t newlen)

(which matches FreeBSDs sysctlbyname(3)). In ns-3-nsc, the INetStack
methods can be called from the NscTcpL4Protocol class.

And here the fun begins: sysctl() is non-portable, in all aspects.
For example, nsc's Linux 2.6.18 stack glue has to do some (really basic)
sysctl_name parsing to build the (integer) vector that is expected by
the Linux kernels do_sysctl() function.
Also, the sysctl_name itself is stack specific, e.g. Linux might have
a 'net.ipv4.tcp_sack' sysctl that you can set to 0 or 1 to
enable/disable TCP SACK support. FreeBSD has 'net.inet.tcp.sack.enable',
and so on.

So while something like
.AddAttribute ("net.ipv4.tcp_sack", "enable/disable Linux TCP SACK support",
IntegerValue(1),MakeIntegerAccessor(&NscTcpL4Protocol::SysctlGetLinuxNetIpv4Tcp_sack,
		 &NscTcpL4Protocol::SysctlSetLinuxNetIpv4Tcp_sack),

might look great at a first glance, I don't think this will work out in
practice. We'd have to add dozens of those attributes (and methods) for Linux alone,
and we'd have to add many more for every single stack in nsc.

Bottom line: I'd like to just hand string/value pairs to NSC without
looking at the content, it will be enough work to handle those in the
nsc stack glue code...

Same goes for setsockopts -- while there is a substantial set of portable
values, there are also several stack specific ones. So the same applies
here: I'd like to avoid them completely and just hand them down to nsc.
I think its safe to assume that setting a sysctl value is more
important than retrieving its current setting, so what about something
like

tcp->SetSysctl("net.ipv4.tcp_sack", 1);
tcp->SetSysctl("net.ipv4.tcp_congestion_control", "cubic");

(for retrieving sysctl settings its even worse, because there
is now way to know if that sysctl returns an integer value or cstring
or... )

Maybe we can talk about this on irc after tomorrows ns-3 irc meeting.
I'd also be interested in hearing about opinions on what I should work
next. Personally I think it would be best to first add getpeername
to nsc (to add the SocketRxAddressTag),
but perhaps I've missed something more obvious/beneficial.

Thanks,
Florian
-- 
Florian Westphal <fw at strlen.de> // http://www.strlen.de
1024D/F260502D 2005-10-20
Key fingerprint = 1C81 1AD5 EA8F 3047 7555  E8EE 5E2F DA6C F260 502D