Dynamically adjust tunnel count based on usage
Opened 14 months ago
Last modified 12 months ago
#2703newenhancement
Dynamically adjust tunnel count based on usage
Reported by:ReportageOwned by: Priority: minor Milestone: undecided Component: apps/i2ptunnel Version: 0.9.45 Keywords: tunnel allocation, i2ptunnel Cc: idk Parent Tickets:
Sensitive: no
Description
Instead of static tunnel count allocation, enabling dynamic tunnel count based on either bandwidth usage or remote destination count, would conserve resources both locally and within the network by not creating more tunnels than needed, for both client and server tunnels.
The option could be toggled with a "Dynamic tunnel allocation based on usage" checkbox, with the default being enabled.
Subtickets
Activity
changed milestone to %undecided
comment:1 Changed 14 months ago by zzz
Cc:idk added
The proposal is to implement something similar to snark's IdleChecker? and make it available to other tunnels as a standard option. Snark does it based on active peer count (streaming connections, roughly). Not bandwidth, not DHT (datagram) traffic.
Unique far-end streaming destinations is perhaps the best metric as that would correlate best with tunnel demand, but even that may need to be tempered with a bandwidth estimate. And it omits datagram traffic. It's difficult to come up with a heuristic that would be suitable for any application's traffic pattern. Currently, streaming counts total connections but not unique far-ends. Probably needs to be based on unique, to make it immpossible for a single far-end to drive up tunnel count.
At first glance this would perhaps have to happen either in, or in close conjunction with, I2CP's SessionIdleTimer?, as a dynamic strategy would replace the simple reduce-on-idle strategy implemented there.
However, I2CP has no visibility into number of streaming connections or far-end dests or bandwidth, and it's probably not the right place to add large tracking data structures. Nor does i2ptunnel know much. Streaming knows the most. So an effective implementation would either have to be in streaming, or 'above' streaming in e.g. i2ptunnel. Putting it in streaming would make it available to all TCP apps, including SAM, BOB, plugins, etc. This would require forcing reduce-on-idle to off if dynamic were enabled.
Alternatively, putting it in I2PTunnelHTTPServer may make sense, as that's a much narrower application target where it would be much easier to design some heuristics. Servers is probably the primary use case anyway.
Security issues like the ability of an attacker to impact tunnel builds need to be reviewed and mitigated.
tl;dr not as easy as it first appears, either in design or implementation.
somewhat related: #2700
-
comment:2 Changed 12 months ago by zzz
Version:0.9.46 → 0.9.45
idk stated his intentions at the meeting this week to get this in for .46, but we agreed in a subsequent discussion that there's no time for that, as it would be sequenced after #2700. This has real potential to break things. Request a patch and plenty of time for testing and review before anything gets checked in.