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

[Rodrigo Fonseca]

Just fillin in Om's last comment about the three aspects of the link
estimator value:
1. Range. 0-100?
2. Delta. What does a change of 5 mean?
3. Depending on the type of the value returned, might be able to
   add, multiply etc to compute bi-directional estimator or
   path metric.

Rodrigo


On 3/9/06, Rodrigo Fonseca <rfonseca at cs.berkeley.edu> wrote:
> 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.
>