Ignoring direct connection to target peer in latest versions (0.5.12 including)

[ri-gilfanov]

Hi guys. It seems to me that the latest changes to the routing algorithm contain some kind of logical error.

Direct connections to geographically distant peers are now often ignored. Instead, traffic often takes a more complex path starting from the geographically close peer.

But if the path is more complex, then usually the latency is higher, the bandwidth is lower, and the packet loss is higher.

Moreover, this behavior dramatically increases the bottleneck effect on some public peers. For example, if a public peer is the best transit point between two clusters of peers.

Now it is unprofitable for geographically distant peers with high bandwidth to have connections to geographically close peers with low bandwidth. Not direct. Not indirect.

In numbers. Having connections to geographically close public peers can reduce the bandwidth between my peers from 50-500 Mbps to 0-100 Kbps. The number of hops increases from 1-2 to 3-4 or more. The latency to the target peers increases from 30-80 ms to infinity.

Identifying and removing connections to the problematic peer doesn't always help. The routing algorithm often finds a longer path for traffic through the same problematic peer.

Bandwidth is more important than connectivity for me. And now I need to monitor the bandwidth of other peers, to find paths with bandwidth "bottle necks" and to isolate my peers from them.

In the past, I solved such problems by reducing the number of hops between my peers to 1-2 hops. Now the routing algorithm seems to ignore the number of hops and rely too much on network latency values.

Is there any way to fix this?

Thanks and sorry for my English