[SensorNetArch] Fwd: HotOS'05 paper submission

[Philip Levis]

Begin forwarded message:

> From: margo at eecs.harvard.edu (Margo Seltzer)
> Date: April 7, 2005 1:21:44 PM PDT
> To: polastre at cs.berkeley.edu, prabal at cs.berkeley.edu,  
> zhao at icsi.Berkeley.EDU, rfonseca at cs.berkeley.edu, pal at cs.berkeley.edu,  
> ct-ee at eecs.berkeley.edu, jwhui at cs.berkeley.edu,  
> shenker at cs.berkeley.edu, istoica at cs.berkeley.edu, get at cs.berkeley.edu,  
> culler at cs.berkeley.edu
> Subject: HotOS'05 paper submission
>
>  paper: 068
>  title: Towards a Sensor Network Architecture: Lowering the Waistline
> author: Philip Levis
>  email:  
> polastre at cs.berkeley.edu,prabal at cs.berkeley.edu,zhao at icsi.berkeley.edu, 
> rfonseca at cs.berkeley.edu,pal at cs.berkeley.edu,ct- 
> ee at eecs.berkeley.edu,jwhui at cs.berkeley.edu,shenker at cs.berkeley.edu,isto 
> ica at cs.berkeley.edu,get at cs.berkeley.edu,culler at cs.berkeley.edu
>
> Enclosed you will find the comments from the reviewers as well as
> comments that arose during the discussion at the Program Committee.
>
> One presenting author will automatically be invited to the workshop.
> If you would like an additional author invited, please send email
> to margo at eecs.harvard.edu and include your paper title, the other
> author's name and email address.  We will try to accommodate as
> many such requests as possible.
>
> You will have a 20-25 minute presentation slot with 5-10 minutes
> for questions.  Since this is a workshop, we encourage you to leave
> plenty of time for interaction and to design your talk to solicit
> such interaction.  You will be contacted by your session chair
> before the conference to discuss the exact details of how your
> session will be organized.
>
> We look forward to seeing you in Sante Fe!
>
> - Margo Seltzer
> Program Chair
> ------------------------------
> They say that the purpose of architecture is to make it easy for  
> systems
> to evolve, but that you pay a penalty in efficiency (the Internet
> architecture is an example). On the other hand, we need top efficiency  
> for
> sensor nets. This conflict is not fully resolved, but is used to  
> justify a
> much more complicated basic communication interface. The proposed  
> analog
> to IP packets is SP: single hop broadcast. There are lots of vague
> suggestions about how this might be used. This should stimulate a lot  
> of
> discussion.
> ------------------------------
> This call-to-arms paper argues that "the primary factor
> currently limiting progress in sensornets is [...] the lack
> of an overeall sensor network architecture", in the sense of
> the Internet architecture.
>
> I don't know enough about sensor networks to know if the specifics
> are right, but I believe in the thesis (that a well-defined
> architecture would increase the rate of progress in sensor
> network research).
>
> Notes to authors:
>
> Please fix cross-references (to citations and figure 1).
>
> Check for capital letters in the middle of sentences (occurs at least
> twice).
> ------------------------------
> The paper discusses the need for a cohesive network architecture in  
> sensor
> networks. The key requirements are as follows. First, name-based  
> routing
> layer that can support implicit multi-cast. Second, the network is to  
> be
> designed along the lines of active networks to allow summarizing of  
> data
> at intermediate processors. Third, auxilary services for networking  
> should
> be designed with rich API's that support call-backs of, for example,  
> the
> power-management layer of the node to the application layer, imquiries  
> and
> the like.
>
> Given the fact that sensor networks are deployed in cost senstive
> environments (cars, toys, manufacturing, health-care, retail), it seems
> that the sort of capability that is pushed and to be supported by the
> network is unrealistic. It bears resmblance to earlier ideas on Active
> Networks, which failed to identify convincing use cases even though  
> they
> were applicable to much less cost-senstive scenarios. Secondly, the
> position paper does not show how this architecture actually addresses  
> the
> needs of various use cases.  There may be a case for a unified
> architecture, but it should probably be much simpler, at least at the
> outset.
> .. Intro
>
> - a problem of the sensor net research may be the lack of an  
> application
> that fits the proposed Intenet-like concepts of: Diffserv-like data
> streaming, hashing of data values and doing logic in the network,
> automated power managemnet, in-network summarization, global  
> addressing,
> etc. Like so many papers on sensor networks this paper is missing a
> convincing application (scenario) that would utilize the proposed
> engineered solution.
>
> .. 2
>
> - Who own the sensors? That may affect the design
> - If the deployment is spatially constrained?
> - How does this architecture relate to the architectures that it is
> replacing e.g., (Profibus, DeviceNet) -- at least at layer 2,3
> - pg 2. second column is unclear--little justification for assertions  
> given
>
> - Figure 1 suggests that SP provides a huge jump in the layer of
> abstraction: bit-trains -- to sthg. like tuple spaces
>
> 4.2
> - the discussion of address free protocols does not really justify why  
> the
> routing protocol cannot be implemented as an application to control the
> network layer as in IP.
>
>
> overall:
> - the paper does not really clarify what the benefit of SP would be
> compared to having IP between sensor nodes, as it is possible to  
> implement
> name-based routing atop IP if one wishes to do so. Many of the auxilary
> service on the left side of Figure 1 already exist in IP netowrks,  
> except
> power management, which is typically implemented at layer 2 or 1.
>
> It is interesting to notice that manufacturing is very keen to  
> leverage IP
> wherever possible, due to its very low cost.
>
> ------------------------------
> This paper argues that we're not going to make forward progress in
> widespread deployment of sensor networks/applications until we
> define (and adhere to) a global architecture.  If we have an
> architecture that defines some common framework, standards, and
> principles (akin to IP and end-to-end for the Internet), then
> people can begin to deploy different applications and different
> implementations of infrastructure components, and we have a chance
> that things will actually run and continue to run.
>
> After arguing this point, the authors then suggest SP (sensor-net
> protocol) as the key architectural element.
>
> So, this paper really has two parts: the first is a position that
> argues for the need for the architecture, and the second is a proposed
> solution.  As such, it's a canonical HotOS paper and could very well
> elicit the kind of discussion and debate that is the goal of HotOS.
>
> The central tenet of the proposed architecture (from page 2) is:
> "a best-effort, single-hop broadcast with a rich enough interface
> to allow multiple network layer components above to optimize for
> a range of potential link layers below in a hardware independent
> fashion."
>
> This principle seems reasonable and the proposed architecture has
> some interesting (and discussion-worthy) ideas such as support for
> both address-free networking and name-based networking.
>
> It might have been nice to demonstrate how some existing sensor-net
> infrastructure maps into your architecture.  That is, if SP were
> the lingua franca, then how might one implement TinyDB in this new
> world?  Would it change?  How?
>
> ------------------------------
> The paper argues that the lack of a network architecture for sensor
> networks is a key impediment for progress in this area, since it  
> inhibits
> integration and interoperability among components designed by different
> groups. The issues are clearly discussed, an initial proposal is made  
> for a
> "narrow waist" protocol for sensor network, and important research
> directions are outlined. The paper leaves more questions open than it
> answers, but it is likely to stimulate new thinking and focus the  
> community
> on key research directions. A great workshop paper.
> ------------------------------
> It is a position paper that makes the argument that sensor networks
> should have a common lingua franca like IP.  They use the analogy,
> but they are only proposing 1-hop routing which doesn't really let
> you reach out and connect to anyone.  HotNets would probably be a
> better venue, but there does seem to be widespread interest in this
> community.
>

-------

"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'