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

[Rodrigo Fonseca]

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.

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.

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.

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.

Thanks,
Rodrigo



On 3/23/06, Philip Levis <pal at cs.stanford.edu> wrote:
> On Thu, 2006-03-23 at 19:03 +0100, henri dubois-ferriere wrote:
>
> >
> > Rodrigo:
> > - Looked at a bunch of multihop collection implementations
> >
> > - Differ in metrics, queuss integrated or not, control messages triggered or
> >   periodic
> >
> > - Control messages:
> >   + Triggered: Drain
> >   + Periodic: about everyone else
> >   Both approaches valid.
> >   Suggests making room for both: a control message has a 'trigger' bit which
> >   forces received to resend a control message shortly after.
>
>
> I was recently reading SIGMOBILE's newsletter and it looks like the
> MANET WG in the IETF has recently decided to move from Experimental to
> Proposed Standard. They're distilling the different continuous and on-
> demand protocols into two new ones, DMYO and OSLR. While I don't think
> the issue they're struggling with (e.g., header customization) are that
> relevant here, it might be good to take a look, from an academic
> perspective.
>
> Phil
>
> _______________________________________________
> net2-wg mailing list
> net2-wg at millennium.berkeley.edu
> https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/net2-wg
>