[Ns-developers] planning the ns-3.4 release

[Gustavo Carneiro]

2008/12/17 Tom Henderson <tomh at tomh.org>

> Craig has started a wiki page for the ns-3.4 release.
> http://www.nsnam.org/wiki/index.php/Ns-3.4
>
> There are a number of known open issues listed, but we need to decide what
> features we are going to try to merge and establish a merge and release
> schedule.  I would like to see a rough plan emerge over the next week, so if
> there are things you'd like to see added for ns-3.4, please suggest them
> now.
>
> We can start to discuss this at today's weekly IRC chat (noon PST, 20h00
> UTC) or later on IRC or on the list.


By 20h00 UTC I have to leave, unfortunately, but I'd be happy to participate
in some discussion up until that time, if you want.

I have couple of comments about the plan:

 1- "Tap Net Device (emulation) Support; ", isn't something like this, or
similar, already part of the 3.3 release?  What am I missing?

 2- In your Ipv4 refactoring you mention *"it seems cleaner to not pass the
packet for forwarding to the routing protocol, but instead to have the
routing protocol just return routes (or a list of routes).*".  I should
mention that passing the packet to the routing protocol is intentional.  It
is done like this to allow source routing protocols, which will want to
insert new header information.

 3- Still regarding Ipv4RoutingProtocol API, it is biased towards reactive
routing protocols, true, but that is to avoid multiplication of virtual
methods, and to make sure that the IPv4 stack always works regardless of
whether the routing protocol is reactive or proactive.  If you provide
different methods for reactive/proactive and source/destination based
routing then you will end up with multiple code paths in the ipv4 stack.
Multiple code paths lead to lack of testing which leads to more bugs.

Regards,

-- 
Gustavo J. A. M. Carneiro
INESC Porto, Telecommunications and Multimedia Unit
"The universe is always one step beyond logic." -- Frank Herbert