Opened 3 years ago

Closed 22 months ago

#2194 closed enhancement (no response)

Make service tunnels available sooner in the build process (and other tunnel enhancements)

Reported by: Reportage Owned by:
Priority: minor Milestone: undecided
Component: apps/i2ptunnel Version: 0.9.33
Keywords: tunnels, availability, quick startup, profiling resistance Cc:
Parent Tickets: Sensitive: no


Currently destinations to services hosted locally are not made available until all configured tunnels are built (main + backup). In order to make services more responsive (especially after startup), once a tunnel has been built, and while subsequent tunnel builds are in progress, the destination should be available to use. This would reduce the amount of time waiting for service availability, potentially addressing timeouts that are experienced when the router starts (update checks, subscription updates etc).

On a related note, when built, traffic should be distributed across all available tunnels, either randomly or per remote destination, with an option to configure the behavior. This would reduce tunnel usage profiling opportunities and make better use of resources by load-balancing traffic. Adding the option to generate a short-lived local destination per tunnel would further reduce profiling opportunities that currently exist to track a destination over different websites, or over time.

To further frustrate profiling efforts over time, by default client tunnels should be configured to generate a new destination on startup, and an option to cycle a client tunnel (automatically stop/start) in order to generate a new destination every x idle minutes should be considered as an option in the tunnel manager.


Change History (4)

comment:1 Changed 3 years ago by zzz

Status: newinfoneeded_new

Not true. A destination is up as soon as it has one inbound and one outbound tunnel. If you have evidence or docs to the contrary, please supply the info, and specify the type of service.

comment:2 Changed 3 years ago by Reportage

Status: infoneeded_newnew

OK, a misconception of my part. What I'm observing more often than not is that multiple outbound tunnels are built before inbound tunnels, which at first glance looks like multiple tunnels are required for a destination to be considered ready.

So, in light of this, is there anything that can be done to prioritize the order of tunnel builds to get the service up sooner? If outbound tunnels are being built before inbound tunnels, alternating the build so that an inbound tunnel build occurs after an outbound tunnel build might shave a few seconds off time to availability. Or if tunnel builds are all fired off simultaneously, is it worth prioritizing one inbound and outbound tunnel before the remainder of the tunnels are built?

comment:3 Changed 3 years ago by zzz

Status: newinfoneeded_new

That priority mechanism is already there. A pool with no tunnels (recall that inbound and outbound are separate pools) is higher priority than one that has tunnels. You can see what builds are in progress on the tunnels page.

For a variety of reasons, inbound tunnels are harder to build successfully than outbound tunnels. Especially if your router is hidden, firewalled, low-bandwidth,not well-integrated, or just started. There are a few changes 3 weeks ago in 0.9.33-15 intended to improve things, should you wish to do some before/after testing.

Other things from OP:

2nd paragraph:

Traffic is distributed randomly across all tunnels, assuming more than one remote dest. We can't do it to a single dest because everything becomes out-of-order, killing throughput. To do it right requires multipath-aware streaming, which is really hard. Search here or on zzz.i2p, you may find some things on the topic.

2nd and 3rd par.:
There are options for close-on-idle and new-dest-on-reopen already, but not the default. All client tunnels are new-dest-on-startup by default. It's not clear what more you're asking for here.

comment:4 Changed 22 months ago by zzz

Resolution: no response
Sensitive: unset
Status: infoneeded_newclosed

closing no response.
Additionally, changes in 0.9.39 start i2ptunnel sooner.

Note: See TracTickets for help on using tickets.