[CUWiN-Dev] CUWiN 1.0 wishlist?

[David Young]

On Thu, Aug 11, 2005 at 01:31:49PM -0500, Bill Comisky wrote:
> On Tue, 9 Aug 2005, David Young wrote:
> 
> >On Thu, Aug 04, 2005 at 12:16:11PM -0500, Bill Comisky wrote:
> >>Dave,
> >>
> >>I wanted to revisit the CUWiN 1.0 discussion.  A number of things have
> >>been fixed, and things seem to be running fairly smoothly here.. good
> >>uptimes, haven't seen nodes dropping into the debugger, etc.  I wanted to
> >>get a feel for where you think CUWiN is relative to a 1.0 release, what
> >>the blocking issues are, and what kind of timeline you expect to get from
> >>0.5.8 to 1.0.
> >
> >First, an update on 0.5.8: I will make a snapshot of my NetBSD sources
> >for 0.5.8.  I believe your routeviz patches should go into 0.5.8; I will
> >commit those and pull them onto the 0.5.8 branch tonight.
> 
> great!

It's a day late, but I've pulled them up.

> >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.
> 
> What I'd like to see is a release we can point to and say that the basic 
> routing is stable, though it may lack the other, mostly routing 
> independent features you mentioned.  Something that communities could get 
> started with soon(er), and have some confidence that things will just 
> work.  How far away do you see a stable routing, no-frills release?  What 
> things are needed to make hslsd "feature-complete"?

I will send a list of things to complete hslsd.  Tell me what you think
of the provisional release schedule, below.

> Whether that release is called .6, .7, or 1.0 seems somewhat arbitrary to 
> me; that is, lacking any existing funding/project mandate for features 
> included in 1.0.

I agree that 0.6, 0.7, etc., are essentially arbitrary, but 1.0
is different.  It is understood that versions less than 1 are not
complete.  1.0, however, is a landmark release.  1.0 should be a complete
implementation of the ad hoc community wireless system that I described
in the OSI grant.  I believe we will alienate users, developers, and
funders if 1.0 is anything less.  I guess you could say, 1.0 is the
"do you see see what I mean?" release.

***

Here is a provisional release schedule for CUWiN, focusing on the "routing
development track."  There ought to be web UI/viz and name service tracks,
too.  Sorry, I have not put target dates to these release versions, yet.

        0.5.8:  for heavy-duty testing of the routing

        0.6:    All bugs we know now, and bugs detected in 0.5.8, fixed.

                To fix one of the bugs, I anticipate a minor architectural
                change to hslsd before 0.6---reference-counting
                linkstates, and changing from internally-linked to
                externally-linked linkstate workqueues.

        *** we will recommend 0.6 for CWNs

        0.7:    HSLS improvements: improve bootstrap condition (handle
                network merges better).  Handle bidirectional links
                according to BBN TR 1301.

        *** in 0.7, HSLS adapts more quickly to changing networks

        0.7.5:    Add linkstate locking and decision/hello/lsu threads.

        *** in 0.7.5, the real-time performance for flooding/hello
        *** protocol improves

        0.8:    Add a gateway-selection protocol.

        0.9:    Debug name service bridge.

        *** the community network looks to zeroconf like a LAN.

        1.0:    Debug route visualization, possibly switch
                from gd to a less buggy graphics library.

        *** development focus shifts back to kernel after 1.0

        1.0.5:  Extract ETT link metric from kernel rate adaptation
                module.  Inject ETT into hslsd.  Experimental release
                with ETT instead of ETX.
 
        1.1:    ETT complete.
 
        *** Following 1.1, a major new development phase begins.

        1.1.5:  Import Virtual AP feature from FreeBSD.  Demonstration
                release with 1-channel OPN and AP+ad hoc on the same
                radio.

        1.1.7:  Demonstrate one-radio/multiple-channel operation,
                possibly with OPN.

        1.2:    OPN complete.

        *** With 1.2, CWNs can be "filled in" with cheap APs.
        *** 1.2 lays the groundwork for a 2nd major development phase.

        1.2.5:  Complete backplane LSA implementation.  Experimental
                multi-channel/multi-radio routing.

        1.3:    Multi-channel/multi-radio routing.  On broadcast networks
                (e.g., "wireful" ethernet) improve flooding efficiency
                and the bootstrap condition.

        *** This release lets us improve performance by exploiting
        *** more channels and more radios, either on the same router,
        *** or on a ring of routers.

        1.4:    Act on interface events (up/down/add/delete) and media
                events (active/no carrier).  Treat point-to-point
                links.  Redistribute routes from other protocols to HSLS.

        *** 1.4 is for the sake of completeness of the routing.

        1.5:    TBD

Dave

-- 
David Young             OJC Technologies
dyoung at ojctech.com      Urbana, IL * (217) 278-3933