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

[Rodrigo Fonseca]

Hi,

here are the meeting minutes from today's meeting. Please report any
inconsistencies, mistakes or omissions.

Thanks,
Rodrigo
---------------

Meeting minutes, March 9th 2006
Present: Phil, Om, Kyle, Henri, Sukun, Rodrigo

Rodrigo:Welcome to Sukun, our new member.
Sukun: introduced himself. Worked on the Berkeley network layer
architecture, and on SP, and his main focus is reliable bulk
transport.

Rodrigo: Berkeley is releasing its version of SP today, pending write
authorization to the TinyOS repository.
Sukun: it is going to be available at tinyos-1.x/contrib/ucb/tos/lib/SP.

Henri: what are the differences in the two instances of SP?
Phil:There are some differences. Boomerang is closest to the paper.
Arsalan revisited some decisions. Phase feedback was dropped, for
example.
In Boomerang it tells you when the packet was sent, that is not in Berkeley SP.
Congestion bit was also not included, as it was not entirely clear what it meant

Om: interface is slightly different?

Rodrigo: another difference is that in the Berkeley SP neighbors are
referenced via handlers, and not addresses. You send to a handler
(which is just an integer pointing to a neighbor table entry). A node
with two radios would be two links for SP, with two handles. Enforcing
network ids is left to the network layer, for example. SP enforces the
decoupling of mac address from network address from node id.

Phil: In T2, network address != mac address != node id. You have a TOS
node id, and an AM address. By default they are the same, but they can
be different.

Kyle: Anything going on on the AM layer?
Phil: It is going to be fair share queueing, virtualized packet
interface. From an SP standpoint, this is not efficient in terms of
energy. This is good for "I want to send a packet" protocols. High
performance protocols should probably be built on top of SP.

Om: About high performance protocol. Is it true that on the 2420 stack
you can send 600 packets/second?
Phil: Yes, but it gets complicated. Will forward the email and explain
over email.

Progress: Gil checked in some code for dissemination, Phil will look
at it on Sunday.
Phil: TOSSIM is functional. Use it as a library, and link to it, or link phyton.
Rodrigo: What about the radio model?
Phil: RSSI based, from studies done by Bhaskar at USC. If you look at
RSSI values you can infer collisions, asymmetric links, etc, given the
right tweaks to the model.

Rodrigo: How do I create a topology?
Phil: Two ways: first is a radio propagation model tweaked for
hardware variance.
In the other, you  take a network, run an experiment, get RSSI value
for each pair.

Rodrigo: So the natural direction is to have a standard measurement
application, a standard file format, and a repository of publicly
available topologies…
Phil: Definitely.

Om: Will this be applicable to CC2420?
Phil: There's a student looking at this. It's a better radio, and
should be applicable. The hardware is better calibrated.

Om: On Collections, I was updating the TEP based on the discussion
last week. Looking at the interfaces for link quality. We could
discuss these.

Om: Link quality. Current impl. uses some form of ETX (boomerang).
Wondering if there are other estimators that can't compute ETX?
(F(asymmetric LQI)?). Other questions are whether the values should be
absolute or relative, and how can we set thresholds in a routing
protocol for very different metrics.

Sukun: Also there's the issue of short term estimation and long term
estimation. Do they need to be separated?
Phil: Estimator should have a well defined interface. ETX is not used
in the source code for Boomerang. There isn't a direct correlation
with ETX.
Original Mintroute: used ETX.

Om: should it be an abstract, linear number, say between 1 and 100? In
our lab we had to write an adaptor for mica2 and micaZ because the
metrics were so different.

Phil: ETX is the metric that you want. ETX is useful. Going with an
abstract notion might be better for now. It's a research challenge to
come up with a good ETX value from different estimators.
Henri: ETX may not be a completely valid notion in some contexts. ETX
ties everything in as the packet abstraction. Error correction
schemes, for example, might only need to retransmit a few bits in the
face of a lost ack to recover the packet at the receiver.

Phil: ultimately you want a measure of transmission cost. Could be a
linear measure,  10 costs twice as much as 5.

Sukun: if you have two radios, blue tooth and cc2420, it's hard to
compare even ETX among them.
Om: two metrics? Quality and cost?
Phil: gets complicated. Cross link cost starts to involve circuitry, etc

Om: SPUtil interface in Boomerang does mention ETX. I was not dreaming.
Phil: This is a munging of LQI, not ETX.

Herni: Single or bidirectional quality? ETX implies bidirectional
quality (because of acks)
Phil: If it is some kind of energy cost, then there is an assumption
of bidirectionality. Interesting going forward how big a deal
asymmetric links are.

Rodrigo: Another variable is how the metric provided is combined over
multiple hops. ETX, for example, can be added directly from one hop to
the other. Probability of transmission is multiplied (which is the
same as adding in the log space). This allows algorithms such as
shortest paths to be run, I think it's an important requirement.
Phil: That is an argument against relative values. You should be able
to combine values across nodes.

Phil: We can go into deep investigations... It's useful to get working
systems and go from there. Berkeley's SP  works on telos only so far.
Boomerang works on TMote-sky. Let's build versions of collection and
dissemination on top of basic AM.

Rodrigo: from these we can get what the protocols actually require
from the link estimation.
Om: there are three aspects: relative vs absolute, composition, <to be filled>

Phil: From recent studies it really matters whether you are in the
edge of sensitivity. I will send a recent proposal with Bhaskar about
link behavior of the CC2420.

Rodrigo: That was a good discussion, we should continue over email.

The plan then is to continue with the implementations, and come up
with what the different protocols require of link estimation.