Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#1595 closed enhancement (not a bug)

Add an option to limit participating tunnel count

Reported by: DjJeshk Owned by:
Priority: minor Milestone: undecided
Component: unspecified Version: 0.9.20
Keywords: Cc:
Parent Tickets: Sensitive: no

Description

My router is using all bandwidth up to limit due to participating tunnels. But router continues to accept tunnel build requests and this slows down transfer speeds for others. For example, previously participating tunnel maximum data transfer speed was over 20KBps, now it is about 6 - 10 KBps.
Limiting bandwidth or limiting connection count does not help getting better network performance. Participating tunnel count limiting should help better.

Subtickets

Change History (6)

comment:1 Changed 4 years ago by Eche|on

Resolution: not a bug
Status: newclosed

There are already limits in the amount of participating tunnel per router.
I2P tries to offer transport capacity, NOT quality of transport. To offer more transports to more users, others need to share their speed with all others. I2P needs lots of tunnels.
Current builtin limits are quite sane on a network base view.

comment:2 Changed 4 years ago by DjJeshk

I2P try to forget about transport quality directly affect connection speed while one connection between client and server over I2P uses only one tunnel. I tried remotely downloading a large file from self and proof at this image: http://baltijateam.i2p/oneconnectiononlyoneusedtunnel.png

PS. my router is participating in over 2000 tunnels with 500KB per second bandwidth limit. Does I2P network speed will be affected if I trick router participate in 10 000 tunnels with same limit? Should be enough with 100-1000 affected peers to keep I2P speed low.

comment:3 Changed 4 years ago by Eche|on

Please READ the documentation on how I2P works, it is all explained in there.
I2P is NOT about transport quilaity at all. It just transports messages from client to server without ANY gurantee of speed.
Also you cannot trick a router in participate in 10k tunnels, if it has 10k routers, it does route them. And if you have had read the documentation, you would have the answer: I2P clients do apply sane limits over all.

comment:4 Changed 4 years ago by DjJeshk

I understand that lower layer of I2P transport has no speed guarantee. There is more layers above that layer. Increasing tunnel count may increase bandwidth and reliability. Even in tunnel count configuration bandwidth aka transport quality is mentioned:

2 inbound, 2 outbound tunnels (standard bandwidth and reliability)
3 inbound, 3 outbound tunnels (higher bandwidth and reliability)

Sounds like you do not expect I2P ever to be fast and qualitative, multiple low quality tunnels could be combined into one qualitative and fast tunnel. You are promoting to read the documentation while official page contains two contradicting statements at http://i2p-projekt.i2p/en/docs :

This page was last updated in November 2014 and is accurate for router version 0.9.17. 
The I2P Project is committed to maintaining accurate, current documentation. If you find any inaccuracies in the documents linked below, please enter a ticket identifying the problem.

You say year 2014 is current? I am not a recycle bin that lets outdated stuff go in. I wont even discuss about not mentioned steps what to do before ticket entering privilege is got and after that developers create circular reference about topic named "read that documentation". Better start documenting context of every tiny wrapper function and formed layers at http://i2p-javadocs.i2p/ . Automatic inclusion of source code and javadoc data in official page for high tech documentation would raise quality for public I2P appearance.

comment:5 Changed 4 years ago by Eche|on

If the lower level cannot give you any speed, the higher levels are absolute useless. You cannot provide anything which is simple not available.
You can increase tunnel count up to 16 tunnels already, no poblem. But every single of them can fail and can be fast or slow. And as long as connections does not split between tunnels, it is not any better than with 2 of them.
You can do a large overhaul of streaming lib and we appreciate the patch. But that does only afflect apps which use the streaming lib.
Andy yeah, with more tunnels, more connections can be used, more bandwidth can be used,.. all noted on http://echelon.i2p/docs/i2pspeed.txt (and in I2P docs on webpage).

If you read the link, you know I2P will never be fast, as RTT on a 13 hop tunnel will never be low.
Thats a physical limit, already discussed a 100 times in forum.i2p and on zzz.i2p
Caching does solve this, but we do not want a single node of I2P cache up to 1 GB data…. (big node, 10k partiticpating tunnel, sums up to a lot of cache).

The documentation is a rolling release and updated as needed and reported. The last big overhaul was 2014, which was noted on that page.
If you find a issue, file a ticket. As you already found out, you can report in forum, in IRC, in trac.i2p - we are happy to receive bug reports.
trac is again open to register new users, but due to heavy spammers (>2000 new spam accounts per day with too much spam), we needed to accept each new user manually. Was far easier to acept a single one instead of removing 2000 fake ones.
But maybe you want to apply to do this job?

The javadocs showing the recent javadocs of the I2P router, which we are working on. The wrapper is not our software project and its documentation is not our job.Search for the java wrapper and the documentation of it on http://wrapper.tanukisoftware.com

The source and docs are included in main page with links, You just have to follow them.

comment:6 in reply to:  4 Changed 4 years ago by killyourtv

Replying to djjeshk:

You are promoting to read the documentation while official page contains two contradicting statements at http://i2p-projekt.i2p/en/docs :

This page was last updated in November 2014 and is accurate for router version 0.9.17. 
The I2P Project is committed to maintaining accurate, current documentation. If you find any inaccuracies in the documents linked below, please enter a ticket identifying the problem.

I fail to see how these two statements contradict each other.

If a page was last updated in 2010 but it is still correctly and accurately describing what it's supposed to describe, that page is not outdated. In this particular instance it says the page was last updated in November 2014 and is accurate for 0.9.17. If a page is still accurate even for newer versions, why should the "last updated" stamp need to be updated? If that is what you are looking for, that is an absurd suggestion. When a page is no longer accurate it is fixed AND the timestamp and version are updated. "Accurate for 0.9.17" does not preclude being "accurate for 0.9.20".

If I'm totally misreading what you're saying here, I'm sorry. Please point out specifically what needs to be updated.

Note: See TracTickets for help on using tickets.