Re: [B.A.T.M.A.N.] [RFC] ELP

[Marek Lindner <lindner_marek@yahoo.de>]

Hi Andrew,

excuse the delayed answers - the wbmv5 was rather intense.  ;-)


> The problem with broadcasting the ELP packets is that they are always
> sent with the most robust coding rate. So ELP gives you an idea how
> good the 1Mbps broadcast channel is, not how good the unicast channel
> the automatic rate selection algorithm is using is. I think we
> discussed mixing in some unicast packets in the forward direction. The
> ELP packets containing the reports would stay the same, and so
> function as node detection. But a node could also send out unicast ELP
> packets to its known neighbours and they would be included into the
> LQ.
> 
> There are obvious drawbacks. More overhead, especially in dense
> networks. It is also not clear if the measurements would be
> better. Unicast packets get a number of retries with fast ACKs, where
> as multicast does not. So multicast might actually give a better
> measure of the link at 1Mbps.
> 
> Do you know if Linus had chance to explore these ideas during his
> GSOC?

the problem is known but we did not have enough time to explore it. One idea 
we had in mind was sending larger ELP broadcast packets every now and then in 
the hope of better estimating the link quality. The feature to increase the 
ELP packet size is part of this patchset and would allow to test this idea.

On the other hand I think we should move towards throughput based path 
decisions. It tells us so much more about what we really care about. Some 
obstacles are waiting for us if we go down this path. Have you ever 
experimented with this approach ?

Regards,
Marek