[net2-wg] Meeting Minutes, March 9th 2006

[Rodrigo Fonseca]

In following the development of the Berkeley SP implementation, and
talking with Arsalan today, I have some comments.

First, I don't want to sound like either implementation is better than
the other. I will state a couple of things about the Berkeley
implementation.

It should not be thought of as necessarily inneficient/weak
implementation. It is probably less tested than the Moteiv's code, but
it will continue to be improved and supported. It keeps with the
original goal of being an abstraction that is designed to work over
numerous platforms and to facilitate research. The wheels are already
in motion to write the link adaptors for duty-cycling, micaZ (just
minor changes), and the CC1000.

On the interface, for people above SP, the implementations are
actually relatively similar.
SPSend, SPSendQueue, SPReceive, SPNeighbor.  There are some minor
differences, with the main being that Berkeley SP is uses a naming
abstraction to not bind itself 16-bit addressing schemes, while Boomerang
doesn't do this. Arsalan took many ideas from Joe's original code, and
Joe also included some of Berkeley's implementation ideas in
Boomerang.

Lastly, it is not fair to say that the Berkeley impl is flat out ignoring it
or, even worse, trivializing it. Quoting Arsalan,
"Furthermore, we just wanted people to get familiar with the
interface, and design their applications for SP.  The duty-cycling is done
underneath at the link adaptor and will not affect their applications; we
have already put in all the functions and state in there to make sure of
that.  Furthermore, we have started planning the duty-cycling version of
link adaptor, so that should be out shortly as well."

Rodrigo

On 3/9/06, Joe Polastre <joe at polastre.com> wrote:
> > I think the basic issue is that while it's clear that the Boomerang SP
> > is probably more efficient than the Berkeley one, getting the Berkeley
> > one to work on platforms besides Moteiv ones is probably going to be a
> > lot easier (among other things, Arsalan has said that he's interested in
> > doing so).
>
> I'd argue that's not true.  Nor do you know Moteiv's plans for SP on
> other platforms :)  The architecture behind Moteiv's SP permits any
> platform to easily be added underneath.

There are already
>
> > I believe that the ultimate goal of the WGs should not be to produce the
> > fastest/most efficient/best implementation, but rather a reference
> > implementation.
>
> Ouch!  Talk about killing any commercial interest...
>
> > Having a reference implementation that works on as many
> > platforms as possible is of course desirable. Other groups can then
> > implement alternative versions that match the reference in interface and
> > semantics. Some of that work (if non-proprietary) may then be folded
> > into the reference implementation.
>
> That's a lot of work == undesireable.
>
> Plus the two implementations don't match in terms of interface.
>
> And just to be clear, our work is not proprietary--it is released
> under a very popular open source free-use license.
>
> > E.g., Moteiv can implement a TMote-specific version of SP which takes
> > advantage of the 8MHz clock, or its fast radio wakeup times. This can be
> > a marketable product -- it's superior to the reference -- but people who
> > are beginning to dabble in the area can use any platform.
>
> People buy platforms from vendors, and vendors supply the software.
> That's how you have so many TinyOS users.
>
> I'm sure if you ask Jonathan, you will find out that 90% of the SP
> work was getting low power operation to work.  By flat out ignoring it
> (or, even worse, trivializing it) you will end up in a world of pain
> and it will take months, potentially years, to get to a reliable low
> power system.
>
> -Joe
>