@eyedeekay
+R4SAS
+RN
+RN_
+T3s|4
+Xeha
+orignal
FreeRider
Irc2PGuest15271
Onn4l7h
Onn4|7h
T3s|4_
aargh3
acetone_
anon4
cancername
eyedeekay_bnc
not_bob_afk
profetikla
shiver_1
u5657
weko_
x74a6
zzz
0) Hi
zzz
hi
zlatinb
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
hi
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
eyedeekay
*is
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) ?
orignal
no
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) ?
orignal
no
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?
eyedeekay
8UTC
eyedeekay
PM
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?
R4SAS
hi
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!
orignal
fine
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()
zzz
}
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.