[Ns-developers] planning the ns-3.4 release

[Tom Henderson]

>-----Original Message-----
>From: Gustavo Carneiro [mailto:gjcarneiro at gmail.com]
>Sent: Wednesday, December 17, 2008 07:46 AM
>To: 'Tom Henderson'
>Cc: 'ns-developers'
>Subject: Re: [Ns-developers] planning the ns-3.4 release
>
>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?

It is mostly there but there are a few details that were judged to be too close to the merge deadline to make Craig comfortable to include in 3.3, so we slipped that feature.  Craig plans to finish this off after the 3.3 release.

>
> 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.

I have to update the wiki page; the most current information is in the two READMEs that are in tomh/ns-3-ip:  README.routing.txt and README.routing.api

Here is what it currently says in those READMEs regarding that point, which basically agrees with what you wrote above:

"The API to lookup routes in the forwarding process has the following 
properties:
- it is asynchronous (callback-based)
- ownership of the packet is conceptually passed to the routing object 
and returned in the callback.  This allows the routing object to implement 
whatever data structure it needs to cache packets when on-demand routes need
to be queried.    

4) We want to make allowances for on-demand protocols.  On-demand protocols 
impose the following requirements:
   1. Identify the need for a route request.
   2. Notify ad-hoc routing daemon of a route request.
   3. Queue outstanding packets waiting for route discovery.
   4. Re-inject them after successful route discovery.
   5. Support callbacks to the on-demand protocol to allow it to expire its
      routing cache

These will be worked as a specific instance of an Ipv4RoutingProtocol.  
Existing ns-3 probably has it basically right in this regard."

It might be nice to add an on-demand protocol sometime soon so that we make sure that we get the routing framework right to support it.

Tom