java config suggestions

zzzi2p commented 10 months ago

Thanks a lot for this, I saw the tweet from Diva.

All my testnet testing has been on LXC, and it's been a while, but I dug up a router.config file, pulled out the important parts, and annotated it for you. Some of these you may not be setting or may not know about. The first one is the most important. If you have any questions, find us on IRC.

# this disables the private IP range checks and a whole
# bunch of other stuff to make testnet work better
# recommended even if you're using public IPs
i2np.allowLocal=true
# adjust as necessary
i2np.bandwidth.inboundBurstKBytes=1953105
i2np.bandwidth.inboundBurstKBytesPerSecond=97655
i2np.bandwidth.inboundKBytesPerSecond=97605
i2np.bandwidth.outboundBurstKBytes=1953105
i2np.bandwidth.outboundBurstKBytesPerSecond=97655
i2np.bandwidth.outboundKBytesPerSecond=97605
# you can set some routers to true to test firewalled
i2np.ipv4.firewalled=false
i2np.ipv6.firewalled=false
i2np.lastIPv6Firewalled=false
i2np.upnp.enable=false
# allow everything readable by everybody
i2p.insecureFiles=true
# just point it to nowhere
i2p.reseedURL=https://localhost:3333/foo
# disable IP blocking
router.blocklist.enable=false
# set some to true and some to false so you have floodfills right away
router.floodfillParticipant=false
# prevent leakage to real network
router.networkID=99
router.newsRefreshFrequency=0
# prevent RI rekey after a long downtime
router.rebuildKeys=false
# accept tunnels right away
router.rejectStartupTime=20000
router.reseedDisable=true
router.sharePercentage=80
router.sybilFrequency=0
routerconsole.advanced=true
routerconsole.welcomeWizardComplete=true
stat.full=true
# NTP
time.disabled=true
time.sntpServerList=localhost

diva-exchange commented 10 months ago

Tx a lot for sharing the options. AFAIK there is/was an issue with the memory footprint of the java router version. k3s with the java router was created a few months ago - but due to the memory requirements of each java router it was out-of-scope to use it in this specific scenario.

zzzi2p commented 10 months ago

Yeah I get it. I've had no problem running 16 java routers in LXC on a 5 year old laptop but every testnet setup is different. Mixed i2pd+java testnets are a lot more complex to set up which is why I've never done it either, but I know it's been done on LXC in the past.

One other suggestion that may apply to i2pd testnets also: Java I2P transports really are much happier with a little latency, and it's a more realistic test. It also helps reduce memory and CPU usage by slowing everything down a little. This may make Java I2P in a testnet less likely to blow up.

On LXC, for example, I do:

tc qdisc add dev eth0 root netem delay 10ms

or, for example, to drop 2% of packets, which is great for testing SSU2 and streaming:

tc qdisc add dev eth0 root netem delay 10ms 2

diva-exchange commented 10 months ago

Very helpful, thanks!

For future references (i2p testnets and divachain testnets) as tested long-term 07-08/2023 on i2p network:

SSU2/UDP: "drop 2%" => "drop 5%" => total drop ratio is according to tests between 20%-30%, tc is applied on container level, hence consider hops (tunnel length). Example: 1.05 ^ 4 = 1.21 (21% total drop ratio, 5% per hop)

Latency: "delay 10ms" => "delay 100ms" => total latency is according to tests between 400 and 800ms, tc is applied on container level, hence consider hops (tunnel length)

zzzi2p commented 10 months ago

Great, I'm glad you're testing with delay and drop. You're right that the drop is exponential, but from an end-to-end streaming perspective, it's 14 hops round trip for 3 hop tunnels. Anything more than a few % drop is just a torture test, you really can't get any useful data on end-to-end speeds when the per-hop drop % is more than say 10%, or even 5%. A good way to test streaming is to disable NTCP2, so TCP won't retransmit before streaming does. Even 2% is very high by network standards, unless you're over wifi, so drop % of 0 or 1 is certainly a valid test also.

10-100 is a good range for latency.

I hope you report to i2pd and/or java i2p any issues or problems that are making testing harder, and of course any actual bugs you find in testing. The java i2p gitlab is at i2pgit.org but you may also report on github if that's easier.

zzzi2p commented 10 months ago

I'm a little concerned about the public IP setup and the possibility of leaking to the regular net. Two suggestions:

if i2pd's reservedrange option doesn't do what you need, please consult with them and ask them to fix it
if i2pd does not provide an option to change the netid, please ask them to add it

then you can switch to a private IP range and be confident RIs will not leak

h-phil commented 10 months ago

Thanks for the config and input.

During a trial and error phase I have started to implement a version with the java client but did not really get it to work (limited time) . There are also some "less documented" options that may cause issues (like the iprestriction option which I believe is part of router.inboundPool and router.outboundPool ). Maybe with your config and some more time I get it to work as well.

I have created three independent issues:

I should have some time later this week.

zzzi2p commented 10 months ago

Thank you very much, I see the i2pd team reacted quickly to your PR. Testnets are great, but what's really great is reporting problems back to us.

I understand your focus on i2pd-only testing , mixed testnets are a headache. Just dropped the info as a reference for you or the next person.

h-phil / i2pd-testnet-kubernetes

java config suggestions #1