[SensorNetArch] Plan

[David Culler]

Did you get my changes of last night.

Joe Polastre wrote:

> Rewrote most of Section 3 (start) through the end of 3.3.  I'm giving
> up the lock (merged my changes with phil's and checked in), and going
> to start working on 3.4 (note that I added the SPNeighbor interface to
> start)
> 
> Section 2 seems almost unnecessary after reading through section 1. 
> David/Scott, can you pass through section 2 and merge it with section
> 1?
> 
> I'm going to get some sleep and modify 3.4, 4, 5, and the single hop
> results of 6 in the morning.  We have all the results now for single
> hop.  Results for multihop are coming along well (we have multihop
> routing running with a minimum delivery of ~96%).
> 
> My current worry is the implications and related work sections.  The
> implications section will need to discuss what other design decisions
> we discarded in this process.
> 
> -Joe
> 
> On Apr 6, 2005 12:35 AM, Joe Polastre <joe.polastre at gmail.com> wrote:
> 
>>I have the lock on sp.tex until further notice (probably about
>>2:30am).  I'm seriously overhauling it based on david's comments.
>>
>>SP does control backoffs, I'll make sure I include that.
>>
>>As for RTS-CTS-- That's a matter of whether the underlying link
>>supports it.  You could image that if "reliability" is set, SP does an
>>RTS-CTS with BMAC, sends with acks, and returns.
>>
>>I think once I iron out the sp section in the next hour or two we'll
>>be in a better place to discuss critical open issues.
>>
>>-Joe
>>
>>On Apr 5, 2005 10:35 PM, David Culler <culler at eecs.berkeley.edu> wrote:
>>
>>>We need to get more of the meet into the network protocol sections so
>>>that we can digest it and think through the implications.  Your new
>>>stuff will help that a lot.  Those sections should hit: what the network
>>>protocol does, how it utilizes SP to do the right thing for both links,
>>>and (in eval) look at how great the numbers are.
>>>
>>>We need to deal directly with the role of broadcast on various links and
>>>what it means for address free protocols.
>>>
>>>The BMAC issues of controlling RTS/CTS, fragmentation, Backoff etc.
>>>don't show up anywhere here.  Is that below SP?  Are those the
>>>equivalent of the games we play with 15.4 slots?
>>>
>>>We have said that every node responds to its address and the broadcast
>>>address.  this is certainly a common link characteristic.  What does
>>>this mean for a multiple name per node model?
>>>
>>>When are we in a place where we can beat our heads against the remaining
>>>open issues?
>>>
>>>
>>>Philip Levis wrote:
>>>
>>>
>>>>I have implemented Trickle and checked it into the repository. A three
>>>>hour bug turned out to be forgetting to set the length field of a
>>>>TOS_Msg, so the trickle sequence numbers were garbage (gah).
>>>>
>>>>I have checked Scott's introduction. It includes many of the concepts in
>>>>the current 2), which correspondingly needs to change (and be shortened
>>>>a lot). I think that 2 should just focus on the specific problem of the
>>>>narrow waist: many network protocols, etc.
>>>>
>>>>I am biking home now and will do a full pass on 3, 4, and 5, wirting the
>>>>Trickle section in 5. Hopefully this will make the three sections a
>>>>coherent and agreeing entity.
>>>>
>>>>I will also put the HotOS submission up on my web page so we can cite it.
>>>>
>>>>The major part that is missing is the
>>>>discussion/implications/conclusion. I will try to put some bullet points
>>>>in here based on my experiences using SP. Someone else will need to
>>>>discard or flesh out as need be.
>>>>
>>>>I fly out to Providence tomorrow. I will have time Thursday evening, and
>>>>can get more done then.
>>>>
>>>>Phil
>>>>
>>>>-------
>>>>
>>>>"We shall not cease from exploration
>>>>And the end of all our exploring
>>>>Will be to arrive where we started
>>>>And know the place for the first time."
>>>>
>>>>- T. S. Eliot,  'Little Gidding'
>>>>
>>>>_______________________________________________
>>>>SensorNetArch mailing list
>>>>SensorNetArch at Millennium.Berkeley.EDU
>>>>http://Mail.Millennium.Berkeley.EDU/mailman/listinfo/sensornetarch
>>>
>>>_______________________________________________
>>>SensorNetArch mailing list
>>>SensorNetArch at Millennium.Berkeley.EDU
>>>http://Mail.Millennium.Berkeley.EDU/mailman/listinfo/sensornetarch
>>>
>>