Clearnet peers Overpower and Dethrone I2P peers in Mixed Mode settings

[absolutep]

qBittorrent & operating system versions

Qt: 6.8.0
Libtorrent: 2.0.10.0
Boost: 1.86.0
OpenSSL: 3.4.0
zlib: 1.3.1
qBittorrent v5.1.0beta1 (64-bit)
Windows 10

What is the problem?

Whenever in a Mixed Mode torrent - if both the kind of peers are present they dethrone I2P peers.

Even though, I2P peers had more transfer speed than the Clearnet peers.

Once, dethroned, the I2P peers slowly fades away until their speed reaches to Zero.

After some time they get back up but do not recover proper speeds until the Clearnet peers goes away.

Image 1 = Clearnet peers enter and then not only slows down I2P peers but never lets them recover their speed until and unless Clearnet peers leaves the torrent swarm.

Image 2 = Slow I2P speed due to Clearnet peer

Steps to reproduce

1. download cross-seeded torrent [public+i2p]
2. uploading starts after completing download.
3. I2P peers going about their transfer
4. suddenly Clearnet peers enters
5. slows down all i2p peers and gets into top spot
6. i2p peers all go away,
7. i2p peers again enter the torrent swarm but their speeds are significantly less than what was before.
8. this state exists until the Clearnet peers goes away.

Additional context

Ideally, What should happen?

Both I2P & Clearnet peers should be getting seeded/leeched at their topmost speed as possible - because both of them should work separately, as in how separate tunnels work

I2P speed goes into I2P torrent speed
Clearnet speed goes into Clearnet torrent speed.

This does not happen, instead Clearnet completely overpowers and dethrones I2P peers and after sometime when Clearnet peers is finished with their transfer the I2P peers rise back to their glory.

Log(s) & preferences file(s)

13-01-2025 10:33 AM - UPnP/NAT-PMP port mapping failed. Message: "could not map port using UPnP[]: no router found"
13-01-2025 10:33 AM - UPnP/NAT-PMP port mapping failed. Message: "could not map port using UPnP[]: no router found"
13-01-2025 10:31 AM - Detected external IP. IP: ""
13-01-2025 10:31 AM - IP geolocation database loaded. Type: DBIP-Country-Lite. Build time: Wed Jan 1 07:52:30 2025.
13-01-2025 10:31 AM - Successfully listening on IP. IP: "::1". Port: "UTP/"
13-01-2025 10:31 AM - Successfully listening on IP. IP: "::1". Port: "TCP/"
13-01-2025 10:31 AM - Successfully listening on IP. IP: "fe80::3-:44b1%8". Port: "UTP/"
13-01-2025 10:31 AM - Successfully listening on IP. IP: "fe80::3-:44b1%8". Port: "TCP/"
13-01-2025 10:31 AM - Successfully listening on IP. IP: "127.0.0.1". Port: "UTP/"
13-01-2025 10:31 AM - Successfully listening on IP. IP: "127.0.0.1". Port: "TCP/"
13-01-2025 10:31 AM - Successfully listening on IP. IP: "". Port: "UTP/"
13-01-2025 10:31 AM - Successfully listening on IP. IP: "". Port: "TCP/"
13-01-2025 10:31 AM - UPnP/NAT-PMP support: ON
13-01-2025 10:31 AM - Encryption support: ON
13-01-2025 10:31 AM - Anonymous mode: OFF
13-01-2025 10:31 AM - Peer Exchange (PeX) support: ON
13-01-2025 10:31 AM - Local Peer Discovery support: ON
13-01-2025 10:31 AM - Distributed Hash Table (DHT) support: ON
13-01-2025 10:31 AM - HTTP User-Agent: "qBittorrent/5.1.0beta1"
13-01-2025 10:31 AM - Peer ID: "-qB5100-"
13-01-2025 10:31 AM - Trying to listen on the following list of IP addresses: "0.0.0.0:,[::]:"
13-01-2025 10:31 AM - Using config directory: C:\Users\AppData\Roaming\qBittorrent
13-01-2025 10:31 AM - qBittorrent v5.1.0beta1 started. Process ID: 3968

[arvidn]

This probably interacts with how the i2p daemon handles tunnels, and how it implements congestion control. I could imagine, perhaps, that i2p attempts to not "push" as hard as TCP, since you may have so many tunnels going simultaneously.

I take it that no peer is using uTP in your example, right? If so, I believe this is all left to the TCP/IP stack and the i2p daemon balancing their congestion control.

[absolutep]

I take it that no peer is using uTP in your example, right?

Well, as per the screenshot from the official website, uTP is not used = Client-to-client connections use the standard protocol over TCP. There are no known I2P clients that currently support uTP communication.

And these are the only types of tunnels allowed in I2Pd setup, as per official documentation

Please, check if this information, is relevant, in solving the issue, thanks.

[Neustradamus]

Linked to:

• Clearnet peers Overpower and Dethrone I2P peers in Mixed Mode settings  qbittorrent/qBittorrent#22160

[Neustradamus]

@zzzi2p: What do you think about this ticket?

[zzzi2p]

BW allocation and peer choke/unchoke strategies are always tricky and I'm sure each client has its own strategy. Mixed mode with one slow and one fast network makes it a lot harder. I'm no expert, ofc i2psnark doesn't do mixed. But I've always suspected Bigly has room for improvement here, I often see Bigly peers that seem unusually slow. Never did bring it up with parg though. The OP issue may take a lot more testing on larger swarms with both Bigly and snark peers, both leeches and seeds, mixed mode and not, both i2pd and Java I2P, to really understand what's going on. Maybe Bigly and libtorrent have similar issues and could collaborate on improvements, maybe not.

I2P is both slower and higher latency than clearnet ofc. Tunnels, congestion control, multiple hops, etc. etc. etc. It's also more variable. One thing that may need to be tweaked for I2P is what I call the BT peer "clock", or the minimum unchoke-to-choke time. If it's anywhere near 5 seconds as is typical for BT clients that is probably not enough time for the speed to ramp up. i2psnark I think is 40 seconds but that may be a little too long as the network is a lot faster than it used to be.

But tl;dr I don't have a lot to offer here, this is mostly about libtorrent (and/or Bigly) internals.

I do recommend you demand the router type/version (Java I2P or i2pd, and version number) and bandwidth limit setting, and perhaps libtorrent bw limits and actual available bw, from any OP with a speed complaint.

[absolutep]

I do recommend you demand the router type/version (Java I2P or i2pd, and version number) and bandwidth limit setting, and perhaps libtorrent bw limits and actual available bw, from any OP with a speed complaint.

I2Pd
Router Caps: XU
Version: 2.55.0
qBittorrent speed = unlimited

It is not a speed complaint per se but Overpowering the I2P peer complaint

Also, regarding uTP implementation - can it be implemented in future to I2P? Is it necessary for torrenting, especially in Mixed Mode?

[zzzi2p]

No plans for uTP and agreed w/ arvidn, no need.

What is on the list is UDP announces but that's stalled until we finish and implement our proposal 163 (datagram2).

Note that any features requiring UDP - UDP announces, uTP, and DHT - also require SAM 3.3, which is a fair amount of work on the client side, and is not currently supported by i2pd anyway.