Opened 4 weeks ago

Last modified 3 weeks ago

#2446 new enhancement

Increase LeaseSet.MAX_LEASES a lot

Reported by: zab Owned by: zzz
Priority: minor Milestone: undecided
Component: router/netdb Version: 0.9.38
Keywords: Cc:
Parent Tickets:


Arctic is running 10 outproxies with 16 tunnels each and would like to instead run a single outproxy. Opening this ticket as an invitation to discuss what are the implications of increasing the maximum number of leases in a leaseset.

Subtickets (add)

Change History (6)

comment:1 Changed 4 weeks ago by zzz

16 is already too much. The limits are the size of the LS, spamming the ff every time a lease changes (the ff will eventually throttle), and making it a little harder for people to use too many resources.

The solution that's in development is proposal 123's meta LS, which provides massive mulithoming. It won't be a "single outproxy" from the operator's perspective, but it will be from the user's perspective. A true "single outproxy" is probably not desirable from a redundancy perspective anyway.

Please elaborate on what "single outproxy" means to Arctic, and why he wants it. I assume his outproxies are not maxed out, that he just set them to 16 tunnels because that was the max. If it was a thousand, he would have done that. It's not clear that 16 is better than 4. You have any data?

Alternatively, please propose what the limit should be, if not 16, and why.

comment:2 Changed 4 weeks ago by zzz

See also http://zzz.i2p/topics/1584 for tunnel quantity guidance

comment:3 Changed 4 weeks ago by Reportage

Regarding configuration of tunnels, allocating the maximum number of permitted tunnels with a static reduced number in the event of inactivity could be further optimized.. from observation it seems that when activity is detected, the maximum number of tunnels is activated again. Implementing a more dynamic solution (as per I2PSnark) that allows the tunnel allocation to grow and shrink according to usage (# connected clients or bandwidth?) might help alleviate heavy resource usage and, at the same time, reduce the load on floodfills when publishing new leases.

Regarding multiple outproxies, in testing it appears that using round robin proxies rather than nominating a single dest from the same pool introduces significant lag. If a pool of 10 RR outproxies can be made to function similarly to a single destination, the need for hosting all leases on a single tunnel definition may be less desirable.

comment:4 Changed 4 weeks ago by zzz

Yeah, snark-like adjustment in i2ptunnel could be quite helpful, if we could get the heuristics right.

Haven't forgotten about retesting the changes from a weeks ago to make the outproxy selection sticky, it should make things better, that's the point. Been busy but will get to it before 39 goes out.

comment:5 Changed 4 weeks ago by zab

Alternatively, please propose what the limit should be, if not 16, and why.

Answering on behalf of Arctic, who has chosen not to participate in this discussion. From IRC (reproduced with his permission):

[12:10pm] arctic: [13:09] .:dr|z3d:. being able to allocate 160 tunnels on a single dest would be, hmm, killer.. for your needs, anyway. one destination rather than 10.

comment:6 Changed 3 weeks ago by echelon

I would suggest 8-12, not to increase the leaseset to much and keep the leases flowing around.
I do know whats like to run a high load proxy/service, and IMHO 8 tunnels are enough for one single dest.
I do know the wish for one dest to run all traffic on, but also we do need to take care of redundancy and not run all traffic to a single point of failure we do not control.
It is not yet well studied what effects running 10 dests on one server with 16 leases each have to the network and concentration of traffic.
(btw, I doubt artic has reached any limit on each of the destination yet).

Note: See TracTickets for help on using tickets.