Re: [PATCH RFC 0/2] Better throughput estimation on half duplex interfaces

[Remi Pommarel <repk@triplefau.lt>]

On Thu, Sep 28, 2023 at 05:33:46PM +0200, Marek Lindner wrote:
> On Thursday, 28 September 2023 14:39:34 CEST Remi Pommarel wrote:
> > Then Orig1 first adapts the Orig0 OGM throughput to T01/2 then forwards it
> > on same interface it received it. Orig2 receives it and first thing Orig2
> > does is checking if T12 is lower than the received OGM throughput (i.e.
> > T01/2), and if that is the case T12 is considered to be the new end-to-end
> > path throughput.
> > 
> > The first issue I see here is that Orig2 does not know the path to reach
> > Orig0 has to get half duplex penalty because it is forwarded on same WiFi
> > interface on Orig1, only Orig1 knows that. Thus if T12 is lower that T01/2,
> > T12 will be chosen as the Orig2 to Orig0 path throughput (i.e PT02) and the
> > half duplex penalty is lost.
> 
> I am not quite following where you see the problem. 
> 
> The half duplex / store & forward penalty is for situations in which batman-
> adv has to forward packets from an interface to another. In your scenario that 
> only is Orig1.
> 
> Why should Orig2 need to care whether Orig1 does store & forward or not?

Because if Orig2 wanted to reach Orig0 through Orig1 the overall throughput
would be impacted but it is not if the expected throughput of its link
to Orig1 is lower than the expected throughput of the received OGM.
> 
> If the direct path from Orig0 to Orig2 is better than the path over Orig1 the 
> metric should reflect that.

In the example there is no direct path from Orig0 to Orig2, the only
way for Orig2 to reach Orig0 is by going through Orig1.

> 
> Maybe you can add throughput metric values to your example and then expand on 
> what you find problematic?

Ok here is an example:

+-------+         +-------+         +-------+
| Orig0 | <------ | Orig1 | <------ | Orig2 |
+-------+    300  +-------+    110  +-------+
    ^                                   |
    |                                   |
    +-----------------------------------+
                     100

Let's say that :

  - Orig0 and Orig1 are connected via a 200Mbps WiFi mesh link (mesh0)
  - Orig1 and Orig2 are connected via a 110Mbps WiFi mesh link (mesh0)
  - Orig0 and Orig2 are connected via a 100Mbps WiFi mesh link (mesh0)

With the current implementation the originator table of Orig2 will show
something like the following:

$ batctl o
   Originator     last-seen ( throughput)  Nexthop         [outgoingIF]
 * Orig0-Main-Mac   0.220s  (        110)  Orig1-mesh0-Mac [  mesh0 ]
   Orig0-Main-Mac   0.220s  (        100)  Orig1-mesh0-Mac [  mesh0 ]

So best path for Orig2 to Orig0 would go through Orig1 with an expected
throughput of 110Mbps. But such a throughput cannot be reached because
Orig1 has to forward packet from and to the same WiFi interface.

If the throughput between Orig1 and Orig2 were to be 160Mbps instead of
previous 110Mbps then the originator table on Orig2 will look like that:

$ batctl o
   Originator     last-seen ( throughput)  Nexthop         [outgoingIF]
   Orig0-Main-Mac   0.220s  (         80)  Orig1-mesh0-Mac [  mesh0 ]
 * Orig0-Main-Mac   0.220s  (        100)  Orig1-mesh0-Mac [  mesh0 ]

Best path being the direct one as it should be.

Thanks

-- 
Remi