[net2-wg] Configure Event

[Arsalan Tavakoli]

---------- Forwarded message ----------
From: Arsalan Tavakoli <arsalan at eecs.berkeley.edu>
Date: Oct 11, 2007 12:15 PM
Subject: Re: contact
To: David Moss <dmm at rincon.com>
Cc: Omprakash Gnawali <gnawali at usc.edu>, Philip Levis <pal at cs.stanford.edu>

David,

Sorry for the delay in response; things have been somewhat hectic.

I like the concept of the configure event, and I actually think it would fit
in quite nicely with the link layer abstraction that we've been discussing
in the net2 meetings.

Like you pointed out, both the implementations which you mentioned have
advantages and drawbacks.  I think the goal is to avoid library
modification, and so the first implementation option I think is a little
tedious.  On the other hand, if multiple layers or modules are responding to
the configure event, this becomes problematic.

I think the link layer abstraction provides a nice way of incorporating this
functionality.  It provides a location accessible by higher layers to access
configuration information for a packet.  Furthermore, we've been discussing
the idea of a policy-manager, which is a modular component within this link
layer abstraction that provides scenario-specific tuning parameters.  You
can imagine defining 'configure policies' for protocols, or groups of
protocols, which frees the protocol from needing to make the calls each
time.  Furthermore, policies can be specified for the different layers,
removing the need for all of them to make configure calls.  I think this is
actually a perfect use for the policy manager, and could be quite effective.


This idea can also be flushed out in more detail with crisper implementation
details.

Thoughts?

Arsalan

>
>
> On 10/3/07, David Moss < dmm at rincon.com> wrote:
> >
> > Hi Arsalan,
> >
> > The core working group talked earlier today about allowing radio stacks
> > to
> > send out a configure(message_t *msg) event when a message is sent into
> > the
> > stack.  There are several different methods to implement this
> > architecture,
> > and we're trying to decide A) if it's a good idea and works with net2's
> > vision, and B) how it should be implemented if it is a good idea
> >
> > The background on it is we want to let libraries like CTP send its
> > messages
> > using low power listening.  To setup CTP to use low power listening, you
> > currently have to modify the CTP library to call the
> > LowPowerListening.setRxSleepInterval(msg, interval) on each message_t it
> > owns.  Rather than doing this, a better solution may be to let
> > configuration
> > take place through an event signaled by the radio stack.  Walking
> > through an
> > example, CTP could send its message into the radio stack like it
> > normally
> > would without modification.  The radio stack would signal out an event
> > through an interface parameterized by AM type (or directly through the
> > AMSenderC configuration that sent the message) asking to configure the
> > packet (possibly multiple events are needed for different layers in the
> > radio stack that require configuration information).  When a module is
> > interested in configuring the outbound packet, it can then call back or
> > return some configuration value.
> >
> > This would let someone download and use an unmodified CTP library (or
> > equivalent, like dissemination) while having the ability to configure
> > those
> > libraries' outbound packets to use low power listening in the radio
> > stack.
> > By using a configure event, we also have the opportunity to remove
> > metadata
> > bytes found at the end of each message_t structure which will save RAM.
> >
> > What are your thoughts on this?  Good idea / bad idea?  How about
> > implementation - should the module that owns the AMSenderC that sent the
> >
> > packet be the only module to setup configuration information, or should
> > we
> > allow any module in the application to setup configuration information?
> >
> > Here's my take on the pros and cons of the two main types of
> > implementation:
> >   * Allowing only the module that owns the AMSender to configure the
> > packet:
> >     - Prevents multiple modules from contending for the configuration of
> > that packet
> >     - May require you to modify the library to setup your own custom
> > configuration, depending on the architecture of the library.
> >
> >   * Allowing the entire system to capture the configure() event
> > parameterized by AM type:
> >     - Easier to create drop-in configuration solutions.   i.e. include a
> > module at compile time that simply listens into CTP AM types and
> > configures
> > those packets to use LPL.
> >     - But it may be easier to get confused if you have multiple modules
> > trying to configure the same AM type.  How would you know two modules
> > are
> > trying to configure the same AM type (#warning at compile time)?  Which
> > one
> > wins
> >
> >
> > Also, if we get rid of the configuration metadata in each message_t
> > completely, then we have this issue of different layers in the radio
> > stack
> > requesting different configuration information.  The low power listening
> > layer is kind of the default for any layer that would request
> > configuration
> > information, but there could be others too:  security layer, link layer,
> >
> > acknowledgement layer, CSMA layer, etc.  Now, in this case it makes
> > sense to
> > make each layer's configuration information be stored in exactly one
> > spot at
> > the top of the radio stack and make it accessible transparently by the
> > layers underneath.  This would prevent you from having to signal out the
> > configure() event a bunch of times and would also prevent you from
> > having to
> > duplicate metadata information in each message_t structure.  Putting it
> > another way, there could be a Config layer in the radio stack that
> > requests
> > and stores the configuration information for the current outbound
> > packet,
> > and other layers defer to the Config layer to obtain their information
> > about
> > how the current packet should be sent.
> >
> > Here's one type of implementation example, there are others depending on
> > the
> > implemented architecture:
> >
> > event void AMSendConfig.configure(message_t *msg) {
> >   call LowPowerListening.setRxSleepInterval(msg, 512);  // or
> > something...
> >   call PacketAcknowledgements.requestAck(msg);
> >   call Csma.useCca(msg);
> >   call Security.encrypt(msg);
> > }
> >
> > Thoughts?
> > -David
> >
> >
> >
> >
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/net2-wg/attachments/20071015/4e14af25/attachment.htm