[CUWiN-Dev] CUWiN 1.0 wishlist?

Paul Smith paul at cnt.org
Fri Aug 12 17:52:30 CDT 2005


David Young <dyoung at pobox.com> wrote on 12/Aug/05 at  3:53 AM:

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

Cool, and btw, Bill totally bootstrapped himself a C hacker in no time
whatsoever. He continues to impress :)

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

I'm really happy to see that 0.6 will be a "fit for public consumption
release. At first I was somewhat taken aback at your one year estimate for
1.0, since it seemed as if based on our feedback and recent list traffic that
we were just around the corner from it, but now I see it was a figment of
my imagination and a function of my ignorance of your original goals (i.e.,
a promise to OSI).

When I'm wearing my other hat in this project, I want to see a 1.0 for all
of the marketing and political reasons that have been expressed. And even
with my engineer hat on, the current set of features meets the (current)
needs of the communities we're working with so I don't pine for the > 0.6
features in the way I do a stable build.

My initial read of the provisional schedule: can we attach a mid-September
date to 0.6 (thinking about Africa).

-Paul

> 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
> _______________________________________________
> CU-Wireless-Dev mailing list
> CU-Wireless-Dev at lists.cuwireless.net
> http://lists.chambana.net/cgi-bin/listinfo/cu-wireless-dev

-- 
Paul Smith            Center for Neighborhood Technology
http://www.cnt.org    Chicago, IL


More information about the CU-Wireless-Dev mailing list