Re: [PATCH RFC 2/2] batman-adv: Better half duplex penalty estimation

[Remi Pommarel <repk@triplefau.lt>]

On Sat, Oct 14, 2023 at 07:10:28AM +0200, Linus Lüssing wrote:
> Hi,
> 
> Thanks for taking your time to look into this and the detailed
> explanations!
> 
> Generally, the issues both patches try to address make sense to me.
> 
> 
> On Thu, Sep 28, 2023 at 02:39:36PM +0200, Remi Pommarel wrote:
> > Let's consider the below topology
> [...]
> > However the following formula seems to be a more realistic approximation
> > of PT_ac:
> > 
> > PT_ac =  PT_ab * LT_bc / (PT_ab * LT_bc)
> 
> Typo, I guess, as this would always be 1? What is actually
> implemented makes more sense to me.

Correct ought to be PT_ab * LT_bc / (PT_ab + LT_bc)

> 
> [...]
> > -	return min_t(u32, lth, oth);
> > +	/* OGM throughput was divided by two for retrocompatibility sake */
> > +	oth *= 2;
> > +	return oth * lth / (oth + lth);
> 
> Could we end up here with a (forged?) OGM that has both the new
> half duplex flag set and a throughput value of 0? While also
> having an lth of 0, therefore dividing by zero here?

Yes good point will add appropriate checks for that and the other
possible integer overflow if this RFC goes further.

> 
> 
> In the following scenario:
> 
> +-------+  ch.1  +-------+   ch.2  +-------+   ch.2  +-------+ 
> | Orig0 | <----- | Orig1 | <------ | Orig2 | <------ | Orig3 | 
> +-------+   300  +-------+  30000  +-------+    110  +-------+ 
>                      ^                                   |   
>                      |                ch.3               | 
>                      +-----------------------------------+ 
>                                       100
> 
> Would the results on Orig3 to Orig0 be these?
> - via Orig2: 300*110 / (300+110) = 80.5
> - via Orig1: 100  <- selected
> 
> While it should have been this?
> - via Orig2: 30000*110 / (30000+110) = 109.6 <- selected
> - via Orig1: 100
> 
> But we can't calculate the latter on Orig3, because we don't
> know the two hop neighbor link throughput? Or am I missing
> something?
> 

No good catch thanks. I can think of a way to fix that but it would
need additionnal info in the OGM to store current half duplex link
speed (maybe to add a TVLV for that). So let's first see if the idea
seems sound enough to go further.

On a side note, the current implementation also has its own flaws for
this scenario. Let's say you consider Orig0 to Orig3 instead and packets
will also go from Orig1 to Orig3 directly instead of bouncing on Orig2.

> 
> Also, this seems to assume that time slices are divided equally.
> That's probably only be true for WiFi drivers that have airtime
> fairness changes integrated? So only recent versions of mt76,
> ath9k and ath10k? Has anyone verified that this works fine not
> only in AP but also in 11s mode?

I don't know how that would behave on setup that does not have airtime
fairness changes integrated, if you think the current dividing by two
approach is better maybe this can be made a configurable option but that
could be tricky ?

For 11s, I have also run tests using mesh points instead of AP/STA and I
have measured similar results.

> 
> And a third concern, but we'd probably have this issue with both
> our current and your suggestion: Would we be off again 802.11be
> and its "Multi-Link Operation" in the future?

This, I have hard time figuring out how MLO would play along with
B.A.T.M.A.N-Adv integration. Unfortunately right now I have no way
to experiment that yet. IIUC the link would be a mix between half and
full duplex, and this would probably complicate things a bit.

Thanks a lot for your review.

-- 
Remi