IRCaBot 2.1.0
GPLv3 © acetone, 2021-2022
#ls2
/2022/08/01
@eyedeekay
+R4SAS
+RN
+RN_
+T3s|4
+Xeha
+acetone
+orignal
+weko
Irc2PGuest5995
Irc2PGuest89954
Leopold_
Onn4l7h
Onn4|7h
T3s|4_
aargh2
anon2
eyedeekay_bnc
hk
not_bob_afk
profetikla
shiver_
u5657
x74a6
zzz 0) Hi
zzz what's on the agenda for today?
zlatinb I'm interested in the SSU2 rollout plan
zlatinb will it be enabled in 1,9?
zzz yes, 1) release planning, deferred from last week
eyedeekay My bad, got signed out, hi
zzz I'll add 2) Connection migration / path challenge/response
zzz what else for the list?
eyedeekay Short go-i2p update as always
zzz ok you will be 3)
zzz orignal, you here?
zzz eyedeekay, how about you go first while we wait for him
zzz 3) go-i2p
orignal sorry
eyedeekay OK not a whole lot to report here except that I've been onboarding what seems to be a potential long-term contributor, apeace
orignal I'm here
orignal yes I'm also interested in SSU2 rollout plan because people are asking
zzz ok, anything else on 3) eyedeekay ?
eyedeekay He's already going through the code and spotting things I probably should be doing, good to have somebody looking at it, his first PR is a refactor of some of the su3 code
eyedeekay That's about all for today
zzz ok, that's good news, another set of eyeballs on it and some coding would be a big boost
zzz let's start back from the top then
zzz 1) release planning
zzz the planned release is in 3 weeks
zzz probably won't be sooner... might be a week later? will have to decide soon
orignal up to you
orignal no rush this time
zzz the posted schedule in the proposal is for a full enabling of SSU2 in the release in 1.10 in November.
zzz we can, of course, do anything we want that's different
zzz so, what are people thinking for this release in 3 weeks?
orignal people want SSU2
orignal because it's much faster than SSU1
orignal R4SAS saw 1.7 megabytes/sec yesterday
zzz you have any test data on that?
zzz vs. what for SSU 1?
orignal not more than 200-300 K
orignal hence SSU2 speed is comprable with SSU2
orignal *NTCP2
zzz I want to throw out the option of something in between enable-for-all and opt-in-only... it could be enabled for some random %, similar to what we've done for rekeying
orignal what I think
orignal for new router always use SSU2 wthout SSU1
orignal for existing routers not sure
orignal enable SSU2 by default additional to SSU1 or let people do it manually
orignal honestly I would prefer replacement if SSU1 is not enabled explicitly
orignal but not sure
zzz for java, I don't have any way to disable SSU 1, and that wasn't in my plans until about a year from now
zlatinb if both are enabled which will be preferred?
zzz java prefers 2 over 1
T3s|4 hi zzz - sure I also want SSU2's speed benefits asap, but not until you're convinced it's stable. The random % rekeying caused no issues on any of my i2p installs - perhaps a similar rollout for SSU2 makes sense.
orignal I understand
zzz on the java side, SSU2 is about 40% slower than SSU1 on a testnet, last I tested
orignal but my question is if you are going to enable SSU2
orignal by default
zzz most likely because of a lack of an ack-immediate flag, which we haven't discussed yet, but that's unproven
zzz well, let's review where we're at
orignal our situation is different, since SSU1 is so bad
zzz - we've been testing since about March?
orignal it's always worth to use SSU2
zzz - about 75 routers in the test ever, maybe 25 are up at a time
zzz - peer test and relay seem to work but are lightly used, because of the low numbers
zzz - we're still finding bugs almost every day
zzz - there's no connection migration yet
RN Hey all. Been a bit since I spoke up. On for new routers, opt in for existing until stability is established, then gradual random...
zzz - Slower than SSU1, for java
zzz end of status
RN if it is already considered stable, then prominent notices in channel topics and news encouraging opt in...
zzz orignal, one thing, I think, is that if you enable it for everybody, you need to plan for maybe .1 and .2 releases a month apart
zzz as I think we will definitely find more bugs, maybe even bad ones
orignal my plan is to enable it for new routers only
orignal no I don't think so
orignal we have implemented almost everything
orignal and we still have one more month
zzz the other thing I'm concerned about is your windowing/flow control/retranmission code, we need to make sure you're not spamming the network with packets
orignal what's wrong with it now?
orignal it's not like SSU1
orignal RTT/RTO and window
zzz I only know what you said, that it didn't have anything yet, maybe that's old information
orignal I mentioned it last week
orignal zlatinb even helped me with RTO calculation algo
zzz ok. that stuff is not easy to get right, so if you have it all working that's great.
zzz you have any data on your retransmission % ?
orignal I copied it from streaming
orignal that worked for many years
orignal no, I didn't measure but will do
RN actually... enabling for new installs before stability is established could lead to bad first impressions... perhaps in install dialouge about it explaining it is still in testing and the option for new install to choose
zzz so, if our goal is to enable it for everybody in November, what % do we need to enable it for in August to have everything well-tested by November?
zlatinb that's the question isn't it
orignal I think it's up to you
zzz is new-installs only enough? too much? not enough?
orignal because i2pd alwyas prefers NTCP2
orignal but you prefer SSU
zlatinb you don't want to single out new installs either
orignal that's the problem
eyedeekay i2p.firefox has got a smaller install base and am still labeled a beta
eyedeekay I can't speak to the effect on the network
eyedeekay if what we want is testing I could enable it there
orignal also cost
orignal should we change it?
zzz Maybe 5 or 10% of the net (a few thousand routers) is a good target?
zzz that's up from maybe 0.1% now
orignal for me even few hundreds is enough
T3s|4 on the i2p-java side, it would be great if there was a dead-drop simple way to allow users in 1.9 to enable both opt-in and opt-out (the default) for SSU2 testing participation, perhaps a new in /confignet. If that SSU2 opt-in capability is added, it needs to be explicitly highlighted in the release news.
zzz well, it's opt-in now via advanced config
zzz I could also do something like 1% at every restart, and once it's on it's on for good, kinda like rekeying
zzz otherwise if it's not sticky, that leads to more issues at restart
T3s|4 yep zzz - understood, and enabled here - just trying to see if there is an easy to enlarge the tester database
T3s|4 easy *way to
zzz at this point the way to enlarge it is to make it automatic
zzz we might get 2x more with more outreach, but I think we're looking at more like 10-100x more
orignal we might also replace it for android
orignal due the CPU usage of SSU1
zzz not a bad idea
orignal alsways replace SSU1 by SSU2 there
zzz so let's leave this as the tentative proposal for now... 1% chance of enabling at every restart, "sticky"... and review it next week?
zzz or anybody else have a concrete proposal?
orignal no, that's just my plan for now
zzz ok, not claiming it's great, but it's something to start from, we can always tweak it in the next 3 weeks
zzz anything else on 1) ?
T3s|4 nope; sounds fair and balanced
zzz thanks to RN and T3s|4 for your comments and suggestions
zzz 2) connection migration / path challenge/response
zzz I really got in deep on it in the last week
orignal yes please xplain what need to be done
zzz the QUIC specs are confusing, not entirely consistent, and I'm not sure even the people that wrote it understand it
zzz so I tried to simplify it and I added a section to our spec
zzz for review at some point
zzz but the plan was always to do it after the release
zzz the one thing we need now is very simple>
zzz when you get a path challenge (which is a PING) send a path response (which is a PONG) containing the same dat
zzz *data
zzz everything else can wait, that's enough for us to do the rest of it later
orignal fine. will do
zzz super. if we have that in before the release, then we'll have a bunch of routers that will PONG, and we can do the rest of it
orignal no problem
orignal will try to do it in next couple days
zzz and if you have time, please review the connection migration section, we'll talk about it in a week or two. eyedeekay you too, I think you had interest in it way back
eyedeekay Yes I did, will do
zzz maybe it makes sense, maybe not
zzz anything else on 2) ?
zzz anything else for the meeting?
zzz eyedeekay, heads up, I put StormyCloud on the agenda for tomorrow's meeting
eyedeekay Yeah I saw, re-read their TOS and stuff to prep
eyedeekay Thanks zzz
zzz orignal, if you have any interest in the outproxy, you may wish to attend our monthly meeting tomorrow in #i2p-dev
orignal what;s about it?
zzz we're looking to make it our default in java
zzz so we're going to review it
zzz ok, that's it for this meeting, thanks everybody
orignal which one?
orignal puroskishi?
zzz no. stormycloud
orignal let me try
orignal what's the address?
zzz you'll need to do your own testing and negotiations with them, not doing that for you :)
orignal no problem
zzz exit.stormycloud.i2p is the outproxy. stormycloud.i2p is the ToS and other info
orignal mtproxy?
zzz there's 8 months worth of discussions on my forum about it
zzz you'll have to ask them about the technology, I've been doing black box testing
orignal I will ask
orignal because mtproxy is also worth
orignal as you know many government monkeys like to block telegram
orignal what time is tommorow?
zzz orignal, I believe the implementation is similar to purokishi;s
orignal what is in EST?
zzz 4:00 our time
zzz orignal, did you say a release in 3 weeks, about Aug. 22, is ok for you guys?
zzz R4SAS, Aug. 22 ok for you?
R4SAS I think I'll as always start at sunday - 08/21, so it is.
R4SAS ok for me, but <see above>
zzz ok great. 3 more weeks of bug fixes!
zzz ok. of course if we run into problems we can always push it, let's see how it goes
orignal I will be busy ar 4 unfortunately
zzz ok, the logs will be posted after the meeting on our website, and there's lots of background on my forum
zzz in case I wasn't clear, what I was proposing for the "sticky 1%" ssu2 enable, more or less:
zzz if (getConfig("i2np.ssu2.enable") == null && random(100) == 0) {
zzz setConfig("i2np.ssu2.enable", "true");
zzz saveConfig()
orignal 1/100 ?
zzz yup
zzz 1% at every restart, save it if now enabled
zzz so it will stay enabled
zzz if you want more routers, make it 2 or 5 or 10%. Remember only half of the routers are on the latest release 3 months later... so 1% may be too low... I'll think about it
zzz and we don't have to do the same %. You could do more than me
obscuratus If you add instructions for how to enable ssu2 in the news release for 1.8.0, I'll bet you'll get a fair number of people enabling it on their own.