[net2-wg] Today's meeting notes

[Rodrigo Fonseca]

Participants: Martin, Phil, Sukun, Arsalan, Rodrigo, Om
Scribe: Rodrigo

Rodrigo: Phil, can you talk about the status of the code, the RPM, the release?

Phil: packaged up, third iteration on RPM due today. It would be good
to look at the
current rpm and check that the correct parameters are there, check
that the code is the same.

I'll send a message on where to get the rpm.  No need to do full
installation tests, this is a sanity test: parameters.

Rodrigo: Om, can you do that?

Om: sure. Phil, did the directory locations change?

Phil: no, still in tos/lib/net/collection. Data structures moved into
the system.

Phil: Queue started to get used in power manager.
(Aside on the power manager:)

Resource management: how do you share resources? tinyos-1.x has
polling. t2 has a resource manager: if you want to use a shared
resource, you issue a request and some time in the future receive a
granted event. Shared resources like buses, adcs use the resource
manager. Sensor driver does a request on the adc. For shared
resources, there is an arbiter which is also a power manager: it
grants requests and can also power down if there are no requests
pending. You then have queues of requests.

R: When is the next release cycle and what should we do for that?
There are two things for the tree routing code: one is adding
dsdv-like sequence numbers, and the other is implementing a better
replacement policy for the routing table.

Om: do we want to do LQI, RSSI based estimation? An issue there is
that we might want to separate the code for the link estimator in a
part to exchange bidirectional estimates and another to actually
estimate them.

phil: first step is to incorporate data traffic, with acknowledgments.
if you can do it on a per data packet basis, you can potentially do it
quite well. I have a student doing this.

Om: yes, sender should influence the estimations, because it knows
what happens to the packets.

Phil: Let's step up a bit, what do people want to work on? Martin, Arsalan?

Sukun: I am working on a protocol specification right now.

Arsalan: interesting to me is something like SP. what is it going to look like?
I will take a look. This is a good opportunity to revisit some of the decisions.

Phil: A good way to start is to write a draft for a TEP, with concrete
proposals, interfaces.

Om: This is how we started the work on Collection and Dissemination,
and it's a way to get things moving.

Martin: like what I see in terms of collection and dissemination. A
focus on low power is important. The link estimator should be plug and
play. I am also an interest in seeing zigbee implemented. A better
place to start would be Zigbee 1.1, which is not released yet.
Zigbe has AODV, many to one, somewhat under definition, it'd be great
if it were defined with academic-oriented people also behind it.
Tthere is a spec available. (1.0) but with several wholes.
802.15.4 and 802.15.4b. low power strategy defined in 802.15.4b has problems.

It depends on how involved the group wants to be highlighting
concerns, but the net2 group is a good place for that to happen.

15.4 doesn't lend itself to low-power operation.

Phil: Upcoming in this year's Sensys is a number of papers on how to
do low power on cc2420, interesting to see how that will influence
zigbee.

In Boomerang, there's tdma, table, communicate your intervals, it's
lighter weight.
There is a paper (I don't know if it will get in) on how to do
low-power listening on the cc2420: it's a kind of RTS-CTS: when are
you awake you issue RTS, RTS, RTS, for the long preamble period. Then
the CTS means I'm awake now.

Arsalan: Is that actually the inverse of low power listening?

Phil: It's analogous to low power listening: the receiver can just
wake up and listen if there's any one willing to send to it. The
difference is that it can know whether it's the destination of any
packet, and can go back to sleep immediately if not.

Martin: we've been doing some work to highly characterize radio
traffic, per packet metric data of the entire network as it's behaving
in a periodic way, or event based way. We're using RadioMetric
interface, it allows a radio driver to signal out any time packets are
sent or received, with radio state interface, clear channel rssi, it's
pretty cool, you get a lot of data. One cool idea is to analyze
periodic traffic, and also poisson traffic, and you get some sort of
statistically arriving events. We're just beginning, it's a LOT of
data.

Martin: One concern is that SP pushes down a number of abstractions
that traditionally belong in the network layer to the lower layer.

Arsalan: In a sense that's true, but it keeps mechanisms without
policy. Policies are implemented above.

Phil: It seems Arsalan is going to start with a proposal of what a
data link layer could look like. Martin is currently interested in how
you collect data about the radio. That is interesting because one
cannot collect data on a lot of testbeds, but with a common interface
and framework a lot of people can, and can contribute back the data.

Martin: That's my current interest, I am also very interested in
reading the TEP.

Rodrigo: ok, that seems like a plan for the week, we look forward to
seeing the starts of such a TEP.

Om: we are going to continue the call to discuss some collection issues.