[net2-wg] call notes 23/3/06

[Philip Levis]

On Thu, 2006-03-23 at 13:34 -0800, Rodrigo Fonseca wrote:
> Thanks Phil. DMYO is an evolution of AODV+DSR, while OSLR is Link
> State Routing with optimized flooding of information.
> 
> Coming back to one of the points on the discussion, you seemed scared
> of a link estimator that would generate traffic on its own.

Hrm. That's not what I meant, so I was probably (as usual) being
completely unclear. I think it's OK for a link estimator to generate
traffic. What I was uncomfortable about was a data link layer generating
traffic on its own, as its policy might dominate energy considerations.

A link estimator sitting on top of an L2 or L2+ interface can definitely
generate traffic. If the link estimator is part of an L2+, then
something above needs to prompt traffic for it to make estimates. This
is the approach that SP takes (or at least used to): there was a "scan"
command which would let you populate the neighbor table. But as far as I
understand its implementation, SP didn't send additional packets
(besides those required by the MAC layer, such as beacons).

> I would put this a bit differently: if you want to use a link
> estimator based on PRR, you need to have a minimum rate of traffic.
> You can choose among link estimator modules, and if the one you choose
> is RSSI based, you don't need any extra traffic.

Yes.


> The way the minimum rate estimator would work is that it piggybacks
> its information on outgoing packets, and reads it on the receiving
> side. If no traffic is seen within the period of the minimum rate, it
> generates a packet with only the piggybacked information. On the other
> hand, if there is periodic traffic coming from a another module (say
> the tree formation module), it can then use those as estimators for
> PRR.

That makes sense.


> The separation of link estimation from the topology formation I see as
> the way to go. Link estimation is a one-hop function that belongs at
> the link layer. It is separated in SP. It is extremely reusable among
> different protocols, and should not be redone for each protocol.

I think that, in the abstract case, you're right. The question then is
whether, as part of collection, we're writing a completely general link
estimator, or a link estimator for collection. That decision affects
what packets are modified/viewed, etc. 

Phil