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

[Rodrigo Fonseca]

> 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).

This may be an artifact of there never having been a PRR link
estimator for SP. AFAIK, both implementations of SP use only
packet-based estimators (LQI,RSSI,etc). Here the SP designers can
correct me if I am wrong, but in a thought exercise to have a PRR
estimator in SP, I would see three options:

  1. when specifying SP for your app, you choose PRR estimator => you
have to pay a minimum rate
  2. you specify SP with PRR, and create a module above it that
implements "minimum rate". This is less efficient than the former
case, but you might be able to get info from SP on the rate at which
it's sending.
  3. you specify SP with PRR, don't have enough info to estimate
qualities, and you go home...

> 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.

We don't need a completely general link estimator, but It doesn't need
to be coupled. It should be straightforward for the collection
implementation to work on another link estimator that is produced in
the future. As you said, we don't have to nail it, but rather allow
for it to be extended in the near future.

>
> Phil
>
>
>

Rodrigo