IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2022/07/08
@eyedeekay
+R4SAS
+RN
+acetone
+not_bob_afk
+orignal
Irc2PGuest93403
Leopold
Minogami
Onn4l7h
Onn4|7h
ProRu
anon
eyedeekay_bnc
j6
polistern
profetikla
qend-irc2p
weko_
x74a6
zer0bitz
zzz orignal, R4SAS, stormycloud is having trouble with their i2pd routers being ipv6-firewalled
zzz about half of them are... all in the same datacenter
zzz they don't think they are actually firwalled
zzz maybe it's because older java releases are banning them? or maybe not? any ideas?
zzz but ipv4 seems fine
zzz orignal, I started getting some termination blocks from i2pd last night. outbound sessions only, ipv6 only
orignal it's known issue
orignal false statement
orignal ipv6 shows firewalled
orignal nothing to worry
StormyCloud Is there a way to verify ipv6 is working correctly? About half of our routers are not showing an IPv6 in the SSU field
zzz how can StormyCloud configure to force ipv6 non-firewalled?
orignal the problem is with older Java release that publish they are capable for peer test
orignal but actually the are not
orignal hit Run peer test from the web console
orignal StormyCloud it's just an issue with SSU ipv6 peer test
zzz is there a fix available where you don't use old java peers ? or is there a config setting ?
orignal zzz and no I didn't change anything in termination logic yet
orignal but for me it's not a big issue
orignal if ipv4 is good
zzz the thing is, they have 75 floodfills over there, and they're not working that great. should they just disable ipv6?
orignal I think it's different issue
orignal if they are not working great it means ipv4 is not working great
orignal ipv6 has less impact in this case
zzz in java we have a setting i2np.ipv6.firewalled=false to force non-firewalled
orignal I don't have this option yet
orignal it's the first time I hear about it
orignal they can try to diable ipv6 but I doubt it would help a lot
zzz the thing is, we prefer v6 over v4, so it's hurting latency for ff lookups. Also, since the routers are flip/flopping between firewalled and not, I think that's what makes them less reliable
zzz not 100% sure though
orignal let them disable ipv6 then
orignal for this release
orignal SSU is end-of-life anyway
orignal and SSU2 works right
zzz sure but when firewalled then they don't publish NTCP2 address either
orignal also be aware about major internet outage in Canada
orignal but they still publish ipv4 NTCP2
orignal hence i2pd will pick it
zzz the v6 issues have been like this for months, they are just getting to investigate it
orignal since ipv6 is not reachable by NTCP2
zzz they also have a java router in the DC, and we are trying to figure out if it's a real ipv6 problem or not
orignal months?)) I would say more than an year
orignal and it's known issue
zzz ok good to know. stormy hasn't been around a year :)
orignal huh? telnet to NTCP2 ip:port
orignal from outside
zzz yeah I tried that, it worked.
zzz but I didn't know if they had intermittent problems
orignal then it's this false alaram
orignal me too
orignal I thought it's not a big deal to worry about
StormyCloud no intermittent problems here :P
orignal so be aware that 2/3 of Canada is without Internat now
zzz maybe not a big deal. But it confused us as we're trying to figure out why the java router over there was having problems
zzz StormyCloud, is the java router in your DC up? I don't see it any more
zzz lucky you're in the good 1/3
StormyCloud Yes, it is the outproxy is running java
zzz that's the one that I couldn't reach the other day, and I still can't. Can't even find the RI
orignal also FYI after that fix with 65 SSU2 peer test is almost 100% correct
zzz re: 65, great
orignal I run a router without SSU
orignal and network status comes from SSU2
orignal last peer test 10 minutes agot
orignal 10:10:32@269/debug - SSU2: PeerTest msg=5 code=0
orignal 10:10:32@269/debug - SSU2: PeerTest msg=4 code=0
orignal 10:10:32@269/debug - SSU2: PeerTest msg=7 code=0
dr|z3d zzz: you're looking for routerid -Ym2 (or perhaps another, I think stormy's got 2 up right now?)
zzz yeah the two not in their DC seem to be fine. I was having zero luck with a 3rd one in their DC
orignal the most popular error code is 68 now ))
zzz dr|z3d, and that's what sent us down a ipv6 rabbit hole
dr|z3d hmm.. if the 3rd one is on the same ip range as Tor exits, that of itself might be causing connectivity issues. dunno, but what I do know is that Tor's been on the receiving end of a protracted DDOS for the last few weeks..
zzz StormyCloud told me it was ready for testing, I started testing, and the one at jZwr was a total fail
dr|z3d not sure which one that was, maybe the azure based one.. that had some issues with ipv6 unrelated to java.
dr|z3d if it was that one, it's been retired from service anyways.
zzz ok. all I know is StormyCloud asked me to start testing and I did. If one of the multihomes was a zombie, that should have been addressed first
zzz because we've been down that rabbithole for a couple days, wasting time
zzz you can't try to run a reliable service on a flaky router, and definitely not if zero-hop
zzz the problematic one was jZwr on 22.x.x.x
zzz *23.x.x.x
StormyCloud My apologies I did not realize ipv6 was an issue when we deployed the third server
zzz any connectivity flakiness is going to be fatal with 0-hop
StormyCloud Well 144x machines are fine
orignal also you should enable ipv6 in i2pd's config only when you know that it work
orignal that's why it's off by default
StormyCloud There are no issues with IPv6 on the I2PD router flee
orignal i2pd also support links over yggdrasil
orignal just FYI
zzz ok so in summary, DC ipv6 is fine, i2pd v6 peer test is flaky, the bad outproxy in the DC is removed, the other two outproxies should be good, we can continue testing
zzz right?
orignal I think so
zzz great, thanks for the help orignal
orignal anyway my goal is to have an option to replace SSU but SSU2 for the next release
orignal to resolve all these issues
zlatinb is there a plan for the rollout of SSU2? What will be enabled by default in 1.9.0?
orignal my plan is to replace it if ssu if not enabled explicitly
zzz zlatinb, we haven't decided yet, it really depends on how reliable it gets in the next month
zlatinb I will bundle 1.9.0 with the Q3 release of MuWire (~2 months after release) so that should be plenty of time to decide whether to enable SSU2
zzz the current schedule is to enable it in 1.10.0 in November
zzz I'm thinking a middle ground would be to enable it for say 10% of the routers
zzz we really need to focus on fixing any basic data transfer issues in the next month
zzz and I think I'm going to propose adding an ack-immediate flag to get the speed up
orignal I always use "ack-immidiate"
orignal I send ack after each batch of message if there is something in it
zzz what's a batch? one packet?
orignal I read a packet then check if more packets in the socket
orignal I keep reading then while they are for the same enpoint
orignal or not more packets
zzz is that the same as you did for SSU 1?
orignal it's batch
orignal and I send Ack after each batch, not packet
zzz have you studied how efficient that is compared to delayed ack? I really think delayed ack would be better
orignal my point is
orignal due the nature of I2P most likely it's one way communication
orignal and no worth to not do batching
orignal all high-load apps do it
zlatinb batching makes sense ofc
zzz true, but it's still not efficient to send a lot of tiny ack packets
zzz we have a lot of success in streaming with delayed ack + an ack-immediate flag, that's why I'm going to recommend it here as well
orignal yes, delays ack maybe the next step
orignal it's just not implemnted
zzz it's also what we have in SSU 1
orignal streaming is usually 2-way communications
zzz I believe that SSU 2 is slower than 1 in my tests because we don't have the flag for 2
orignal while Transport is below tunnels
orignal we see SSU2 much faster that SSU1
zzz with 1-way communications, ack efficiency is much more important, because in 2-way it's often "free"
orignal <R4SAS> 2.5 средняя
orignal e.g. 2.5 Mbytes
orignal per sec
zzz testnet or live net?
orignal and I2P is mostly one way
orignal client side zero hops
zzz with what RTT?
orignal server side 1 hops
orignal <R4SAS> средний RTT на 8 стримов ~130
zzz ok, one hop
zzz that's the streaming RTT or the SSU2 RTT or the ping time between the two routers?
orignal let him ask more
zzz 2.5 sounds pretty good :)
orignal not as good as 12 for NTCP2 ))
orignal but much better that SSU1
zlatinb time to implement the fancy window formulae :)
orignal I don't have window yet
orignal well I do
orignal but it's 128 packets for now
zlatinb I was thinking in the future we could use a predictor for the delayed ack value
zlatinb start with 0 and based on the batch patterns fine tune
orignal maybe
zzz what we're doing now on the java side for ssu 1 and 2 is working well, but it can be improved with an ack-immediate flag and a max # of pkts before acking
zzz I've been reading the QUIC guidance
zzz you don't want to ack too many pkts at once because that leads to bursty transmissions at the other end unless there's metering
zzz and we don't do metering
zzz never have
zzz and no round-robin in the throttler either
orignal there is a lot of room to improve
orignal but even now my SSU2 is better than SSU1
zzz w00t, now persisting tokens across restarts