[SensorNetArch] HotOS

Sun Jul 17 12:04:19 PDT 2005

Prabal and I are going to work through a draft for the CR today. As the CR 
is due on Wednesday, I'd like to organize those who want a hand in it 
before the next SNA meeting. I'll suggest a tentative time of early Monday 
afternoon, say, 1PM. If you want to take part but will not be in Berkeley, 
we can do a conference call. If that time is problematic, send me other 
options and I'll compute an intersection.

After Prabal and I meet today, we'll send out notes on the direction the 
paper is taking.

Phil

----------------------

Society can and does execute its own mandates: and if it issues wrong 
mandates instead of right, or any mandates at all in things with which 
it ought not to meddle, it practises a social tyranny more formidable 
than many kinds of political oppression, since, though not usually 
upheld by such extreme penalties, it leaves fewer means of escape, 
penetrating much more deeply into the details of life, and enslaving 
the soul itself.

           - John Stuart Mill, "On Liberty"

On Tue, 12 Jul 2005, Rodrigo Fonseca wrote:

> Hi,
>
> sorry this didn't go before. I will mail the next one on Monday.
>
> Agenda for tomorrow:
> * discuss the Sensys paper: reviews below
> * 802.11 vs SNA:
>  Joe's link: Section 11.2 of 802.11-1999 is as good as it gets. 
> http://standards.ieee.org/getieee802/download/802.11-1999.pdf
>  AP MAC-Overlay paper: An overlay MAC layer for 802.11 networks. 
> http://doi.acm.org/10.1145/1067185
> * discuss the HotOS camera ready: 
> http://www.cs.berkeley.edu/~pal/pubs/sna.pdf
> * Phil will take a position on how to describe SP: is it a protocol or an 
> interface?
>
>
> Cheers,
>
> Rodrigo
>
>
> ------------------
>
> <Review #1>
>
> Please provide a short summary of the paper:
> This paper proposes an architecture to provide a uniform interface
> between network protocols and link protocols in sensor networks. The
> proposed Sensornet Protocol (SP) is meant to provide a unifying
> abstraction as the "glue" between various existing network protocols
> running over a broad range of link-layer technologies. This approach
> can potentially enable network optimizations as multiple coexisting
> protocols can cooperate in how they use resources and share
> information.
>
> The authors discuss the conceptual view of SP architecture and show
> through implementation of SP in TinyOS on top of two different
> platforms (Mica2 and Telos) that various commonly used protocols can
> benefit from the use of SP's unified interface both in terms of
> network performance and implementation overhead.
>
> What are the main strengths of the paper? (1-3 sentences):
> This is a well written paper that is technically solid. It addresses
> an essential problem of how to support an ever growing pool of
> sensornet protocols, applications, and hardware platforms within a
> clean and stable architecture. This proposal is a timely first step
> toward a mature sensornet architecture. In some sense, the proposed SP
> abstraction can assume the role of being the universal "glue" in sensor
> networks much like IP in the Internet.
>
> While the community has started to realize the need for a cleaner
> layering structure in sensor networks than the status quo, this is the
> first paper that proposes a realistic architecture and evaluates it
> through actual implementation code in TinyOS.
>
> What are the main weaknesses of the paper? (1-3 sentences):
> The evaluation sections can be improved, especially in the "Multihop
> Benchmarks" section. The presentation of the result is a bit confusing
> as is. Please refer to below "detailed comments" for suggestions to
> improve.
>
> Also, there are some errors in the text while referring to related
> work (network protocols). For example, PSFQ is referred to as a
> routing protocol that assumes nearby nodes can overhear transmissions.
> This is not true because PSFQ is a reliable transport protocol that
> can run in either broadcast mode or unicast mode, and it assumes
> overhearing capability only when running in broadcast mode.
>
> Similar errors are found in Table 5. PSFQ and RMST are mis-quoted as
> congestion control protocols while they are actually reliable
> transport/dissemination protocols. For good examples of congestion
> control protocols, the authors can consider to reference the work CODA
> (from Columbia University) and FUSION (from MIT).
>
> Your qualifications  to review this paper :
> I know a lot about this area
>
> Novelty of paper:
> This is a new contribution to an established area
>
> Overall paper merit:
> Top 10% but not top 5% - Paper is between the top 5% and top 10% of
> submitted papers, in your estimation
>
> Please provide detailed comments for the authors:
> This paper proposes an architecture to provide a uniform interface
> between network protocols and link protocols in sensor networks. The
> proposed Sensornet Protocol (SP) is meant to provide a unifying
> abstraction as the "glue" between various existing network protocols
> running over a broad range of link-layer technologies. This approach
> can potentially enable network optimizations as multiple coexisting
> protocols can cooperate in how they use resources and share
> information.
>
> This is a well written paper that is technically solid. It addresses
> an essential problem of how to support an ever growing pool of
> sensornet protocols, applications, and hardware platforms within a
> clean and stable architecture. This proposal is a timely first step
> toward a mature sensornet architecture. In some sense, the proposed SP
> abstraction can assume the role of being the universal "glue" in sensor
> networks much like IP in the Internet.
>
> I liked the way the paper is structured and how the ideas are
> developed. In terms of novelty the authors borrow many ideas from
> existing protocols (as they should) but the kudos here is their
> careful design of a clean and narrow interface that sits between the
> link layer and the network layer, with special considerations to
> support many commonly used network protocols and link technologies.
>
> The provision of a message pool and neighbor table management in SP,
> in my view, is right on target in consolidating the cross-layer
> interactions of many existing sensornet protocols. This is also the
> key to optimize efficient use of shared resources. Many existing
> protocols are already using these two mechanisms (i.e. batching
> messages for bulk transmission and maintaining neighbor table)
> in their own ways and implementations. It's nice to consolidate these
> mechanisms within a unified interface.
>
> The evaluation sections can be improved, especially in the "Multihop
> Benchmarks" section. For example, the congestion control mechanism
> supported in SP is only evaluated in single hop environments. Although
> SP is built upon a best-effort single-hop broadcast primitive, it
> would be interesting to see if this primitive provides any benefit in
> heavily loaded multi-hop environments. On another note, the data
> generation rate used for evaluation of MintRoute is probably too low
> (a packet every 3 minutes?) to show any performance benefits of using
> SP. A well-known problem of multihop data forwarding is the serious
> degradation of network throughput, it would be more meaningful to
> evaluate MintRoute on SP with moderate load instead of the current
> very light load.
>
> The presentation of the result is a bit confusing, it might be better
> to subsection the last three paragraphs in Section 6.2 on page 11.
> The result for evaluation of Trickle shown in Figure 10 is a bit
> confusing.
>
>
>
> </Review #1>
>
>
> <Review #2>
>
> Please provide a short summary of the paper:
> This paper proposes a unified link layer abstraction to allow for easy
> retargetting protocol software between different physical layers. The
> key idea is to provide a unified send/receive interface with the added
> value of shared neihbor managemnt and a shared message pool, offering
> possibilities for all kinds of low-level optimization. The feasibility
> is demonstrated through implementation work on two platforms
> (mica2+telos) and 3 network protocols (MintRoute, Trickle, Synopsis
> Diffusion) with good results.
>
> What are the main strengths of the paper? (1-3 sentences):
> Well written/argumented paper
> Impressive amount of implementation work
> Good evaluation section
>
> What are the main weaknesses of the paper? (1-3 sentences):
> Too much material/too dense, which makes it somewhat hard to digest
>
>
> Your qualifications  to review this paper :
> I am an expert on this topic
>
> Novelty of paper:
> This is a novel direction and contribution
>
> Overall paper merit:
> Top 10% but not top 5% - Paper is between the top 5% and top 10% of
> submitted papers, in your estimation
>
> Please provide detailed comments for the authors:
> - page 2, column 1, paragraph 4 "while TDMA-based protocols ... can
> make this an invalid assumption": this can be said for any MAC
> protocol that implements (some form) of "overhearing avoidance", so
> why do you bash on TDMA??
>
> - page 3. column 1, par 2 "power scheduling": I have no clue what you
> are referring to ... what is power scheduling??
>
> - page 3, column 1, par 5 "ans allows SP to decide when to listen,
> receive, transmit, and sleep": Great, however, I still have troubles
> imagining how to implement overhearing avoidance with SP after reading
> the complete paper. Can you somewhere spell out how to handle
> RTS/CTS/DATA/ACK?
>
> - page 3, column 2, par 2 "when a new candidate node is detected": who
> is detecting it? Some link layer, then it does not make sense to
> inform it again, which is what you imply with "SP asks each link and
> network protocol ..."
>
> -page 4, column 1, par 5 "One solution to this problem ... for future
> traffic": this left me wondering how on earth you can detect that a
> phase shift is necessary. The additional info later on did not make it
> totally clear to me ... How do see that at the lowest level? Does the
> appl needs to get involved??
>
> - page 5, line 7 "it resets the reliability field to false": this left
> me wondering what the success argument of the sendDone is for? Is it
> redundant?
>
> - nextSend(): I understand the need for streaming, but would like to
> know what happens if some packet does not get acknowledged. Do you
> then avbort the message? How is the upper layer signalled? Or do you
> continue with th enext packet?? Tricky (at best)
>
> - cancel()/change(): the possibility to work on the message pool
> requires the ruting layer to maintain a shadow administration of all
> essages that are still outstanding. Does not feel right.
>
> - page 5, column 2, par 2 "An example use of the listen bit ..." I
> dont get how a parent sets the listen bits in its chioldren when it
> wants to push data down the tree.
>
> - sect 4.1: Slotted protocols like S-MAC and T-MAC need synchronize
> the nodes in the network, and therefore to account for clockdrift. I
> have no clue how this could be done within SP, especially not when
> multiple radios are present.
>
> - page 7, col 1, par 4 "may trabnsmit packets with short preambles
> immdeiately" Do you mean back-to-back? If so, you are heading for
> collisons, right?
>
> - page 7, col 2, par 3 "MintRoute checks ... at its ETX" How can this
> be? Do neighbor beacons contain ETX information, cant be true ...
>
> - page 7, col 2, par -1 "FPS ..." You can/should drop this paragraph
> completely because you do not use FPS in any of your experiments and I
> am drowning in information already. Same goes for the 1st paragraph on
> the next page.
>
> - Table 3: you show that you reduce the complexity of the MintRoute
> protocol by switching to SP. Great, Can you tell me how large SP
> itself is, so I can judge whether you just moved code (from MintRoute
> to SP) or that there is really a code decerease?
>
> - page 11, col 1, par -1 "density .. nodes per hop" I have never seen
> this metric for describing node density ... do you mean a connectivity
> of 5??
>
> - refrence [20]: can you please refer to a real publication?
> somebody'shome page is to vague.
>
>
>
>
>
> </Review #2>
>
>
> <Review #3>
>
> Please provide a short summary of the paper:
> The paper presents the design, implementation and evaluation of the SP
> protocol. SP supports a link
> abstraction that can be used by a wide variety of
> network protocols and runs over different MAC; the
> paper evaluates SP over 802.15.4 (TDMA) and B-MAC
> (CSMA). Key components of SP include common neighbors table, message
> pool, and support for network protocol
> indicators for reliability and delay sensitive message,
> and link layer support for indicating congestion and
> phase shift.
>
>
> What are the main strengths of the paper? (1-3 sentences):
> This is very strong paper and will be well received by the community
> mainly because it borrows well understood techniques and bundles them
> into a protocol that could provide some convergence instead of each
> protocol rolling its own set of support mechanisms.
>
> SP is a first step toward providing a common interface set of
> mechanisms that can run over different links supporting a wide set of
> established and future networking protocols. Its an effort to provide
> some commonality for developers of network protocol and
> standardization as technology (links) evolve.
>
> It is also a very well written paper and develops out the argument for
> a standard protocol and standard set of mechanism (tried and tested
> ones) in nice manner.
>
> What are the main weaknesses of the paper? (1-3 sentences):
> One could argue that many of the proposed mechanisms and interfaces
> are already part of TinyOS (e.g., B-MAC, MintRoute) or are borrowed
> from existing network protocol design. What the authors have done is
> generalize out the existing mechanisms (neighbor table, buffering
> pools, congestion control bit, link reliability switch, batching, duty
> cycle management, phase shift, LPL, etc.) and interfaces and repackage
> them as a common layer/interface/abstraction.
> So in terms new ideas I see little but in terms of deep thinking about
> what is out there that is useful and reusable and what could provide a
> common interface then the paper is very strong.
>
> While it is difficult to evaluate SP the evaluation section is not
> fully convincing. I don't buy some of
> the conclusions about SP out performing monolithic protocols. But I do
> see that SP can take advantage of multiple protocols running on a mote
> to exploit batching or to take advantage of the duty cycles of
> individual protocols both in performance (opportunistic scheduling)
> and smaller footprints (common SP interfaces/ components e.g., a
> single neighbor tables). Other quick comments: the TOSSIM stuff seemed
> an odd departure from experimentation as proof, and many of the
> protocols evaluations were of the line - we implemented them over SP
> therefore it works -rendering any real evaluation of multiple,
> distinct protocol evaluation over SP, as almost null and void.
>
> Your qualifications  to review this paper :
> I know nothing about this area
>
> Novelty of paper:
> This is a novel direction and contribution
>
> Overall paper merit:
> Top 5% (and potentially award quality) - I will fight hard to accept this 
> paper
>
> Please provide detailed comments for the authors:
> I think this is an excellent paper. Like all papers it does have holes
> but I think SP is a great step forward for the community. To some
> degree it follows on logically from B-MACs programmability of the MAC
> towards providing a common, useful set of mechanisms for programming
> new network protocols.
>
> The main strength of the paper is the borrowing of these well tested
> mechanisms and their formulation into a protocol layer. The other
> contribution is that to some degree the paper shows that by have a
> narrow waist SP can exploit the execution of multiple protocols - say
> a kin to multiplexing - by saying energy; this makes sense and is a
> very nice attribute of SP since motes do run multiple protocols
> already, and will do more so in the future.
>
> The weak point of the paper is the evaluation. This could be fixed up.
> First many of the experiments don't explicit state what the traffic
> load is or which sources are transmitting. Therefore, we a lack of
> detailed experimental set up it is hard to appreciated the results. I
> thought the TOSSIM section added little and could be removed. Authors
> don't explain why the flip to simulation other than a fuzzy sentence
> of lack of resources. The discussion of the evaluation of the various
> protocols is superficial - we implemented them they worked!
>
> Other issues:
>
> 1) It was not clear to me how nodes determine that congestion occurs.
> SP magically assumes the link can set the congestion bit. How? It
> might be good to come up with a common SP approach to determine
> congestion, e.g., based on channel measurement/ msg pool thresholds.
>
> 2) It wasn't clear what triggers phase shift and how applications
> (protocols) used that, and how the results produced a better
> performance. Many protocols have included randomization of
> transmission to support the idea of phase shift and it makes sense but
> in this paper I did not see how this was proven to work. It is sort of
> left hanging.
>
> 3) I was surprised that SP does not provide a common wire packet
> header/payload specification. I really did not buy the arguments in
> the conclusion that tried to offset this glaring omission. You'd
> expect a common protocol to specify a common message format and
> header. This is a weakness of the paper.
>
> 4) This use of IP TOS includes delay and reliability, and many MACs
> enable ACKs to be switched on an off. The paper uses ideas from the
> literature and it might be a good idea to be more upfront and just
> cite what the authors think the common existing set are and their goal
> to bundle and prove value. I think the paper is not clear enough of
> this right now and a new reader may not know innovation of what is new
> in the paper and what already exists. This could easily be fixed.
>
> 5) Not sure if I buy that most applications are period.
>
> 6) Table 5. PSPQ => PSFQ I assume. Also PSFQ, RMST' function is not
> congestion control but reliability.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> </Review #3>
>
>
> <Review #4>
>
> Please provide a short summary of the paper:
> This paper describes SP, a protocol designed to support a
> variety of physical devices and network protocols.
>
> What are the main strengths of the paper? (1-3 sentences):
> The paper is thoughtful and well-argued.  It makes a good
> case for the proposed architecture, basing its arguments
> on simplicity and necessity.  The authors demonstrate an
> example implementation of their proposed protocol.
>
> What are the main weaknesses of the paper? (1-3 sentences):
> Perhaps for reasons of length (the paper is 14 pages), the
> paper omits detailed arguments for some of its assertions.
> The passive voice is used at times, so that the agency
> being described can be hard to understand (as in this
> sentence).  The implementation section does not demonstrate
> a mixture of physical node types.
>
> Your qualifications  to review this paper :
> I have passing familiarity
>
> Novelty of paper:
> This is a new contribution to an established area
>
> Overall paper merit:
> Top 10% but not top 5% - Paper is between the top 5% and top 10% of
> submitted papers, in your estimation
>
> Please provide detailed comments for the authors:
> This was a terrific paper.  Clear, well-argued, and
> convincing, at least to this non-expert in protocol design.
>
> My only significant criticism is that the implementation
> section seemed to demonstrate SP only on homogenous
> networks, i.e., networks consisting of only a single
> physical node type.  Isn't one of the points of SP that
> it will (or is intended to) support inter-operation of
> arbitrary nodes, just as existing wired network
> protocols support this?
>
> In section 2.1, you state that "each packet is not handed
> to SP until the link is available."  Please rewrite this
> and other such statements in the active voice, making it
> clear which component is performing the action.  Here, for
> example, how is the gating mechanism you describe achieved?
>
> The paper is well-written and copy-edited.  One typo was
> in Section 2.4:  "emphasizes on" should be "emphasizes."
>
>
>
> </Review #4>
>
>
> _______________________________________________
> SensorNetArch mailing list
> SensorNetArch at Millennium.Berkeley.EDU
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/sensornetarch
>