[Tinyos Core WG] Fwd: [Tinyos-devel] message_t

Wed May 6 09:33:19 PDT 2009

In my view, the real question is whether we just want to replace the current
packet format, encapsulation and serialization architecture that is tailored
to the AM stack with another fixed architecture tailored to IP, or we should
try to introduce a more flexible architecture that will allow continued
experimentation in the interweaving of the protocols. Both are valid
options. If we agree that the protocol layering is a done story, than the
overhead of the additional flexibility can not be justified. If we still
want to be open here, we should try to come up with a more open approach
that will enable easy implementation of several different "stacks". I am not
proposing that we should pay the price for something completely flexible
like the "protocol heap" idea. But we can try to find something in between a
fixed encapsulation and heaps. For comparison, the RIME architecture in
Contiki uses a conceptual model for the headers based of attributes and
values that are only solidified in a concrete serialization format before
the packet hits the link layer (
http://www.sics.se/~adam/dunkels07adaptive.pdf), allowing for great
flexibility in composing the different layers above the LL.

Vlado

On Wed, May 6, 2009 at 16:22, culler <culler at cs.berkeley.edu> wrote:

> I think that it is time we allowed ourselves more room to maneuver.
> The active message concept was important to establish how
> communication and computation need to be efficiently integrated.  The
> key elements of that are (i) event-driven dispatch on receipt and when
> the transmit buffer can be reclaimed, (ii) handler namespace, and
> (iii) not requiring arbitrary buffering in the communication
> subsystem.  The traditional sockets API and parallel program message
> passing interface, e.g., MPI, do not have these properties.  However,
> an event driven UDP interface can be created that does.  It means that
> Port serves as the AM handler ID.  It also means that we think about
> encapsulation from the beginning - transport / routing / link.  I
> realize that the message_t discussion can be had without taking a
> position that it is time to eliminate AM in favor of something that
> looks like sockets, but I think that it would serve us well to make
> that step and gain some focus.  Things like group_id were hacks we
> through in for the first TinyOS bootcamp in 2001.  It was not well
> architected.  Ports is a sufficiently large name space for tiny devices.
>
>
> On May 5, 2009, at 11:11 PM, Philip Levis wrote:
>
> > Apologies: Jan should also have been on the message_t list of
> > discussants.
> >
> > Phil
> >
> > Begin forwarded message:
> >
> >> From: Jan Hauer <hauer at tkn.tu-berlin.de>
> >> Date: March 11, 2009 12:36:48 PM PDT
> >> To: TinyOS Development <tinyos-devel at millennium.berkeley.edu>
> >> Subject: Re: [Tinyos-devel] message_t
> >>
> >> Attached is a proposal for an alternative message buffer abstraction
> >> that allows variable-sized protocol headers/footers, but still uses
> >> static allocation of the message buffer. We have not discussed this
> >> in
> >> detail, so ... go on and take it apart :)
> >>
> >> Jan
> >>
> >> On Wed, Mar 11, 2009 at 6:53 PM, Philip Levis <pal at cs.stanford.edu>
> >> wrote:
> >>> As developers have started implementing standards on TinyOS,
> >>> message_t
> >>> has started to show some limitations. The goal of message_t was to
> >>> allow software to pass messages between different AM link layers
> >>> without copying, and this involved several simplifying
> >>> assumptions. As
> >>> systems need more complex link layers (e.g., more than one 15.4
> >>> addressing mode, security support, IPv6 on top of 15.4), some of the
> >>> design decisions have started to become problematic.
> >>>
> >>> For example, message_t requires that the header, data, and footer be
> >>> allocated separately. Depending on your 15.4 addressing and other
> >>> options, the header can be anywhere from 3 to 30 bytes or so.
> >>> Correspondingly, the payload can be anywhere from 120 to 95 bytes or
> >>> so. While the two of them have, in combination, a maximum length
> >>> (125), you have to allocate the maximum of each of them separately,
> >>> leading to about a 20% waste (150 bytes).
> >>>
> >>> This has led core to start looking at other message abstractions.
> >>> It's
> >>> important to note that changing the underlying buffer abstraction
> >>> used
> >>> by radio drivers does not mean we have to break AM-based software
> >>> compatibility: many of these issues are arising exactly because
> >>> TinyOS
> >>> needs more than just AM. At the worst case, you just make a single
> >>> copy between the AM layer (message_t) and other buffer abstraction
> >>> that drivers and other stacks use.
> >>>
> >>> Jan (TU Berlin) is going to send out one proposal he's come up with.
> >>> Stephen (Berkeley) also has some thoughts, and I encourage
> >>> everyone to
> >>> examine the proposals. This is hopefully something that will change
> >>> for 2.1.1, or if more involved than anticipated, maybe a later
> >>> version.
> >>>
> >>> Thanks,
> >>>
> >>> Phil
> >>> _______________________________________________
> >>> Tinyos-devel mailing list
> >>> Tinyos-devel at millennium.berkeley.edu
> >>>
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
> >>>
> > <T2_packet_proposal.txt>
> >>
> >> _______________________________________________
> >> Tinyos-devel mailing list
> >> Tinyos-devel at millennium.berkeley.edu
> >>
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-devel
> >
> > _______________________________________________
> > Tinyos-2.0wg mailing list
> > Tinyos-2.0wg at millennium.berkeley.edu
> >
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>
> _______________________________________________
> Tinyos-2.0wg mailing list
> Tinyos-2.0wg at millennium.berkeley.edu
> https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-2.0wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://www.millennium.berkeley.edu/pipermail/tinyos-2.0wg/attachments/20090506/83a49d11/attachment.htm 