Re: [B.A.T.M.A.N.] [RFC 15/23] batman-adv: ELP - send unicast ELP packets for throughput sampling

[Antonio Quartulli <antonio@open-mesh.com>]

[-- Attachment #1: Type: text/plain, Size: 1923 bytes --]

On 12/02/14 10:12, Andrew Lunn wrote:
> On Tue, Feb 11, 2014 at 01:48:15PM +0100, Antonio Quartulli wrote:
>> From: Antonio Quartulli <antonio@open-mesh.com>
>>
>> In case of a unused link, the throughput estimation will
>> get stuck to the last sampled value and therefore the
>> reported metric will becomes obsolete.
>>
>> Send unicast ELP packets to each neighbor to trigger throughput
>> sampling on unused links.
> 
> Humm, i can understand the need for this, but i really think the rate
> control code should be sending the probes, not batman. What do the
> wifi people say about this? Have they tried submitting patches to
> them?

I am CC'ing Felix so that he can give his opinion.
But last time I checked Minstrel I realised that it uses data packets to
probe rates (there is not a specific probing packet), meaning that if
there is no data packet to send, then no probing is performed.

Sending this ELP packets (when there is no unicast traffic) is a way to
trigger this mechanism in Minstrel.


> 
>>  	/* Instead of updating the metric each "received" ELP packet, it is
>>  	 * better to do it on each ELP sending. This way, if a node is dead and
>>  	 * does not send packets anymore, batman-adv is still able to timely
>>  	 * react to its death.
>> +	 *
>> +	 * The metric is updated by following these steps:
>> +	 * 1) if the hard_iface if wifi => send a unicast ELP for
>> +	 * probing/sampling to each neighbor
>> +	 * 2) update the metric value of each neighbor
> 
> Might be worth pointing out here, that because of queuing, there is no
> guarantee the ELP packets have been send yet and the RC estimated
> bandwidth could be up to 100ms old.

OK, I'll make it explicit. Actually this routine is no meant to get a
"real time estimation", also because the routing algorithm would not be
that fast to react on time.


Cheers,


-- 
Antonio Quartulli


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]