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
no
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
StormyCloud
fleet*
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
StormyCloud
Correct
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
no
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
yes
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
live
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
yes
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