[CUWiN-Dev] CUWiN 1.0 wishlist?

[Sascha Meinrath]

Hi all,

> I expect for us to go clear through 0.6, 0.7, 0.8, and 0.9 before we get
> to 1.0.  I don't expect for us to release 1.0 for a year or more.  Before
> the system goes to 1.0, hslsd needs to become more feature-complete, the
> name service needs to be debugged and its feature-set needs to be more
> comprehensive, and the web UI needs to let us set up multiple interfaces,
> firewall and bandwidth-shaping, etc.  We also need to improve the route
> visualization.  I also think we need to support more applications "out
> of the box."  Important optional features will include a SIP proxy and
> a captive portal.  All of this will take at least a year.

Both our main funder and several potential partners (and future funders) 
are extremely interested in seeing v1.0 rolled out.  One suggestion I 
would have is to stabilize the existing feature set and release v1.0 
sooner so that we can then seek funding to implement these additional 
features for a "new-and-improved" version 2.0.  I think that releasing 
v1.0, even if it has limited features, is a way to attract additional 
interest/support/partners/funding in the project, and will help us to 
get this development agenda completed -- which is our main goal anyway.

>>I want to make sure we're directing our energy here on those issues needed 
>>to get to 1.0, and also to make sure we're testing/looking for the right 
>>things on our testbed.  Also, I know we've been getting a lot of interest 
>>from different groups (community groups, potential strategic partners, 
>>etc).  It'd be helpful to have ballpark dates to provide them, and also to 
>>help us plan for deployments, upgrades, etc.
> 
> The really important thing to test is the routing.  Virtually everything
> else rests on that.  Here are some things to look for:
> 
>         * router bootstrap: it is important that a node joining the
>           network gets a near-complete set of linkstates quickly.
>           There is a procedure whereby a node downloads its neighbors'
>           linkstates. I describe it in some document in doc/local/. [1]
> 
>         * flooding: every new/changed linkstate should reach most routers
>           in the n-hop neighborhood within 2**(n+1) seconds.
> 
>           (Note: I hedge by saying "most" because linkstates *will*
>            get lost on a wireless network.  I expect the losses to be
>            mitigated by repeat transmissions of the same LSU, esp. on
>            networks of high nodal degree.)
> 
>         * global flooding: every new/changed linkstate should reach most routers
>           in the *entire* network within 150 seconds
>           (hsls_router.c:default_global_ival) or 4 * 2**(netradius+1)
>           seconds, whichever is less.
> 
>         * linkstate purging: a router should purge from its database any
>           linkstate that is not updated for 3 times the global flooding
>           period---i.e., 3 * 150 seconds
> 
>         * database updates: a router should recompute its routing
>           table with Shortest Paths First every tick (4 seconds) that
>           follows the addition/change/deletion of a linkstate
> 
>         * routing table: after recomputation, the routing table should
>           contain the least-metric routes to all destinations that are
>           reachable by traversing directed links in the UP condition
> 
>         * RIB: following recomputation of the routing table,
>           hslsd should add/change/delete the same destination-nexthop
>           pairs in zebra as it adds/changes/deletes from its own
>           routing table
> 
>         * FIB: zebra should load the routes from the RIB into the
>           kernel forwarding table
> 
>         * default routes: if dhcpselect gets a DHCP lease from a gateway,
>           it should re-write the hslsd configuration so that hslsd
>           advertises a default route

I think the testing of the routing is the key to going to version 1.0 -- 
we need to really bang on the software to show that it's stable.  If we 
focused our efforts in testing the routing, I think Dave's points 
provides a fairly good checklist for what we'd need to ensure for the 
release.

--Sascha

> [1] I will describe the procedure briefly here.  Basically, a node says
> "bootstrap me!" and its neighbors start unicasting their linkstate
> databases to it.  A node "echoes" each received linkstate so that its
> neighbors know which ones have been successfully received.  No neighbor
> should send a linkstate to the "bootstrappee" that it has already heard
> the bootstrappee echo.  A neighbor tries up to three times to send
> a linkstate to the bootstrappee before it gives up.  Neighbors send
> linkstates from distant routers before near routers (as measured by hop
> count), they do not send any hopcount-1 linkstates before all of the
> hopcount linkstates have been sent, and they do not send any linkstate to
> a bootstrappee that has been updated since the initial bootstrap request.
>