zzz
successfully split() with matching keys on both sides
orignal
great
orignal
do you publish SSU2 address already?
zzz
no, this is mostly test code
zzz
standalone test, as I did with NTCP2
zzz
data phase success:
zzz
Got I2NP block: [UnknownI2NPMessage:
zzz
Type: 107
zzz
Length: 424]
zzz
Got PADDING block, len: 48 in frame len: 487
orignal
so I can't try to connect to you yet
zzz
oh gosh no
zzz
I said 6 weeks about 2 weeks ago :)
orignal
you didn't get my idea ))
zzz
also, as I said, the header encryption isn't right, needs to be reworked
orignal
since you have Bob side already
zzz
what idea was that?
orignal
I could start with Alice only
zzz
no way, I'm not testing your (untested) Alice for you. Do both sides and test it yourself ))
zzz
I've fixed 100 problems testing both sides
orignal
too lazy to implement both at the time ))
orignal
anyway will do porbably this week
zzz
yeah but we know from experience, testing with somebody else is slowwwwwwwww and painful.
zzz
also, right now, I have a lot of things just stubbed out, doesn't match the spec
zzz
the good news is, the data phase is really easy
orignal
will check
zzz
ok got both data directions working
zzz
0) Hi
zzz
hi
orignal
hi
eyedeekay1
hi
zlatinb
hi
zzz
woo, full house
zzz
what's on the list for today?
orignal
R4SAS is missing
orignal
introducers for SSU2
zzz
ok that's 1)
zzz
I'll add 2) SSU bug post mortem
orignal
fine
zzz
3) SSU2 coding status
eyedeekay1
Are there any release details to discuss?
zzz
4) release schedule
zzz
ok that's a good list for now
zzz
1) introducers for SSU2
orignal
specs don't meantion how they should be published
orignal
I guess it must include s and i
zzz
yeah, the proposal is incomplete about introducers and peer testing, we decided that was "phase 2"
zzz
but yes, to do it properly, it would need s and i
orignal
let me explain
R4SAS
hi, I'm here, but bit busy with android stuff problems
zzz
the relay and peer test blocks also are not properly specified yet
orignal
I started with refactoring
orignal
I want to implement common NTCP2/SSU data structures
orignal
so when I parse a SSU2 address I have to understand how I parse introducers
zzz
I understand
orignal
and data structures for it
zzz
the problem is we haven't even done a full security analysis of relay and peer testing
orignal
I have SSU1's interiducers for now and ofc it's not right
zzz
so I'm not even sure _how_ it's going to work
zzz
like, can we do relay and peer test "out of session" or do we need a full session handshake first
orignal
same way as SSU1, no?
zzz
I don't think so
zzz
I don't think it's secure
orignal
I think we should do it with "N" Noise
orignal
like we do in ratchers
orignal
e.g. no handshake just one time encryption
zzz
maybe
zzz
but with UDP address spoofing, we need a handshake
orignal
another question if we can introduce SSU2 routers through SSU1 and vice-versa
zzz
the problem is that adds one or more round trips to the process
zzz
I don't have any answers for you right now
zzz
good question
orignal
that's fine
orignal
but also SSU2 wothout introducers is useless
orignal
because it's not better than NTCP2
zzz
remember we decided to stop working on the phase 2 proposal and start coding phase 1...
orignal
agree
orignal
so for now I assume SSU2 address doesn't include introducers
orignal
if it does it's error
zzz
yeah, until we figure it out.
orignal
fine. will implement tghis way
zzz
but I think you're right, it would need both s and i
orignal
is and ii ))
zzz
yup
zzz
because I may do SSU and SSU2 on one address, like I did for NTCP2. I'm not sure yet and probably won't know for another 2 months
orignal
ofc I will do SSU2 address only like I did for NTCP2
zzz
all I'm coding now is test code. integrating it into the existing code will be much later
zzz
good stuff, glad you're thinking about introducers
orignal
so is SSU addres contains v it supports SSU2
zzz
yeah I think so
zzz
anything else on 1) ?
orignal
how do you differentiat SSU and SSU2 request then?
zzz
I don't know
zzz
next month ))
orignal
then start use SSU2 addresses only
zzz
my test code publishes both
zzz
but I can change it
orignal
good
orignal
probably no worth
zzz
anything else on 1) ?
orignal
just separate SSU
orignal
yes, one more question
orignal
s
zzz
go ahead, don't mean to rush you
orignal
I'm Bob I receive incoming SSU2 session
orignal
and then Alice's RI
orignal
how do I verify her s?
orignal
SSU2-capable address and transport?
zzz
same as NTCP2. the noise static key must match the s in the RI
orignal
when we had NTCP2 it was only on s
orignal
now we also have SSU2
orignal
do you think it should be the same s and NTCP2 or might be different?
zzz
you look through the RI for the SSU2 address, pull out the s, and check it
zzz
might be different. probably should be different
orignal
and SSU2 or SSU2+transport?
orignal
*any
orignal
e.g. SSU2 ipv4 and SSU2 ipv6
orignal
can they have different s?
zzz
right, that's why the keys should be the same for all SSU2 addresses.
zzz
same rules as NTCP2
zzz
I guess you could look for the v4 or v6 address
orignal
for NTCP2 I look by NTCP2 + transports
orignal
alrhough I publish the same s
zzz
what do you mean "+transports" ?
orignal
but assume they might be different per address
orignal
ipv4/ipv6/ygg
zzz
oh, ok
zzz
anything else on 1) ?
orignal
no
zzz
2) SSU bug post mortem
zzz
I don't care how the bug happened
orignal
tell me
zzz
but I want to talk about how we can find and fix things like this faster
orignal
I know how
orignal
my question is different
orignal
how it has so big impact
orignal
especially since "dropping is good"
zzz
you estimated it was dropping 5%... zlatinb estimated 40-50%
zzz
no protocol can handle 50% drops
zlatinb
5% * 6 hops = more
orignal
but not every how was SSU
zzz
we try to keep the same peers for client tunnels. If we have a bad one, or the same bad one in all tunnels, it's really bad
orignal
*hop
zzz
I saw it the most when I had the same peer as first hop in all outbound tunnels
zzz
so if that connection was SSU...
orignal
it's obvious
orignal
because you prefer SSU
orignal
while first i2pd peer prefers NTCP2
zzz
it's a mix. what we prefer depends on our connection count and conn limits for both transports, and other factors
orignal
how to resolve it faster?
orignal
you must tell me the problem
orignal
because I was not aware for a long time
zzz
yes. I worked on it for two months, and last week I gave up, then zlatinb started doing testnet
orignal
nobody complained
zzz
I complained two months ago, I said it was i2pd
zzz
then a few weeks later I changed my mind
orignal
then you said it was not
orignal
you compained about leasesets
orignal
that they are not published
zzz
it took me a long time because it wasn't my bug :)
zzz
yes, we publish LS through client tunnels
zlatinb
m0ar testnet seems like an obvious answer, no?
orignal
the problem was you didn't identify the problem properly
orignal
zlatinb no quite
orignal
you can use testnet when you know what kind of tests you need to run
orignal
and you must indetify a problem first
zzz
I didn't understand the problem
orignal
you did
orignal
when you said that data didn't go through a tunnel
zzz
one thing for sure, the release was Nov. 29, and network reliability started getting worse almost immediately
zzz
by early December, people were complaining, and IRC disconnects were a lot more often
orignal
I started noticing these disconnect
zzz
we all saw it
zlatinb
I thought RosKomNadzor was blackholing us, so I looked at .ru routers. That was because they had just blocked tor, all in all lucky strike
orignal
after postman went down
zlatinb
what are we trying to solve with this discussion? It is impossible to come up with a bulletproof way to avoid all future problems
zzz
I just felt like I was the only one investigating for two months. Everybody else said 'not my problem'
zzz
not trying to avoid, trying to find and fix faster
orignal
wrong
orignal
you didn't explain details
zlatinb
but if we decide that every transport change needs to run through testnet we have some level of confidence
orignal
like "I build a tunnel trought routes A,B,C and tunnel worked wrong"
orignal
so my point is
orignal
you should shared more info about a problem
orignal
with tehcnical details
orignal
and reproducable cases
zzz
I don't have any tests for the live net that "proves" a router is bad
zzz
I don't think it's possible
zlatinb
I found a bad router manually
orignal
you have given me the list of suspicious routers
zlatinb
single tunnel pool, force that router to be in it
orignal
that's kinda info I expect next time
zzz
most of those suggestions only came a week ago
orignal
but for LS problem for example you could tell what exatly did you di
orignal
FF, tunnels, etc.
orignal
if could help to narrow down the problem
zzz
is there anything you can do in i2pd to make sure SSU gets more testing? this isn't the first SSU problem. Remember when you were dropping after 5 seconds?
zzz
you should use outbound SSU for some % of connections to make sure it's always being tested
orignal
maybe
zzz
how are we going to ever be sure i2pd SSU2 works if it's not ever "preferred" ?
orignal
but you always know that SSU in i2pd is shitty and slow
orignal
SSU2 yes
zzz
use it anyway, so it gets better
orignal
I'm going to implement properly
orignal
while fixing SSU in i2pd is worse than rewrite it completely
zzz
ok
orignal
also I do use SSU
orignal
1. after peertest I have some SSU connections
orignal
and reuse them
orignal
2. Incoming connection if firewalled
orignal
an IB comes through SSU ofc
orignal
one sec
zzz
that's all I have for 2)
zlatinb
I have more
orignal
I give some data
zzz
go ahead
zlatinb
we need to come up with some preventative masures for the future, and I think testnet suite is it
zlatinb
like decide on minimum number of tests before a new release
zlatinb
I'm happy to do them
orignal
SSU ( 824 )
zlatinb
like building tunnels, no tunnel test failures, simple file transfer, etc.
orignal
SSUv6 ( 146 )
orignal
that's FF
orignal
number of sessions
orignal
so SSU it not so rare in i2pd
orignal
NTCP2 ( 1955 )
orignal
olle 2 times less
orignal
2.5
zlatinb
without tests like this the problem can happen again
orignal
and I also have 5) for today
orignal
number of routers in netdb
zzz
ok then let's wrap up 2)
zzz
zlatinb, that's a great suggestion to do mixed testnet testing
orignal
so what's the problem
orignal
yes I agree
orignal
before I had around 5K routers on FF
orignal
and 8K now
zzz
we're still on 2)
zzz
anything else on 2) ?
orignal
fine
orignal
no
zlatinb
I'll come up with a list of test cases
zzz
sounds good zlatinb
zlatinb
and put on wiki somewhere
zlatinb
eot on 2)
zzz
3) SSU2 coding status
zzz
as I said, I got a basic handshake and data phase working
zzz
not all according to the spec, some things are stubbed out
zzz
test code only
zzz
orignal, what's your status?
orignal
ok
orignal
I have started with Noise
orignal
than with RouterInfo and data structures for addresses
orignal
now implementing SessionRequest send and receive
orignal
that's all
orignal
hope to finish handshake by the end of this week
zzz
as I said, the header encryption and header protection need to change. For now, you can follow what's in the spec, or just don't do it at all
zzz
I hope to fix it up in the next week
zzz
and hope to be ready for testing with you in 3-4 weeks, as promised
zzz
I'm also making fixes to the proposal almost every day
orignal
good
zzz
anything else on 3) ?
zzz
4) release schedule
zzz
we plan to release in two weeks, feb. 21
zzz
what about i2pd?
orignal
fine
orignal
we can do it
zzz
the earlier the better to get the fix out there
zzz
eyedeekay1, what did you have for this topic?
R4SAS
fine, but depending on situation maybe I'll want to start it on 20th
orignal
20th is also fine ))
zzz
I'd be happy if you released today, but I know you have your own processes and schedules
zlatinb
I want to run some basic tests in a mixed testnet after checkin deadlines, testing final code for both i2p and i2pd
zlatinb
I want at least one day for that
orignal
I don't want to mark it as 0.9.53
R4SAS
2 weeks ahead, so you won't know what will happen))
eyedeekay1
I didn't have anything specific to the topic that applies to everybody
eyedeekay1
But I was wondering if I should reach into the easy-install bundle router.config files and set router.disableTunnelTesting=false with the installer
zzz
zlatinb, our checkin deadline will be Feb. 18, probably around noon eastern
eyedeekay1
No, right? Since the default has been changed?
zzz
I do plan to leave tunnel testing enabled by default for the release, even though I do have code to not put i2pd .52 in tunnels
zzz
I'm a little concerned about what it will do for conn limits though
zzz
tunnel testing definitely isn't free
orignal
don't do it all time
orignal
do it once
eyedeekay1
Also it's kind of nasty to try and enable on Android without us having any UI for it, dev builds for Android are awesome right now but release builds are not
orignal
after a tunnel was built
zzz
'doing it once' wouldn't catch a peer that only fails 5% of the time
orignal
tunnel either works of not
orignal
*or
orignal
if not build a new tunnel instead
zzz
so you're saying the bug is 100% of the time?
zzz
I'm confused
orignal
peer fails but not session
zzz
we don't ever fail a tunnel after one failed test
orignal
I mean if session fails it fails for good until recreated
zzz
I've enhanced a lot of the testing to find bad peers, and made netdb lookups and stores more flexible also
zzz
so hopefully the network will get better quickly after the release
orignal
my point is even a single peer test is enough
zzz
I'm talking tunnel tests
zzz
that go through two tunnels
zzz
that's 6 routers to blame
zzz
anyway, we're far off the topic of 4)
zzz
anything else on 4) ?
zzz
5) number of routers in netdb
orignal
5k before and 8K now
orignal
I think it's nothing but waste of memory
orignal
we should change the algorithm
zzz
what you keep and what you don't is implementation-dependent, up to you
orignal
no
orignal
I use your cleanup algorithm
orignal
and I think you see the same picture
zzz
I have 3500 on a non-ff and 5200 on a ff right now
zzz
you can use the same algorithm but tweak the parameters
zzz
or change the algorithm. or cache them on disk and flush out of memory
zzz
whatever you want
zzz
"5K before" before what?
orignal
before recently
orignal
before Tor in Russia
orignal
literally
orignal
FF doesn't have an algorithm
orignal
just 1 hour
zzz
I haven't seen such a big increase here
orignal
strange
zzz
so make it half an hour
orignal
maybe it's might be my problem only
zzz
also, don't do exploration on ffs
zzz
no need
orignal
Routers: 4936
orignal
not-FF
orignal
good point
orignal
will change the code to not explore on FF
zzz
another thing that helps is sending netdb responses out exploratory tunnels, so you don't have a million connections to other people's IBGWs
zzz
that you have to look up
zzz
and also rerouting responses to a different tunnel
zlatinb
zzz, orignal: git.idk.i2p/i2p-hackers/i2p.i2p/-/wikis/I2P-I2Pd-interoperability-testnet-scenarios
zzz
getting late, anything else on 5) ?
orignal
no
orignal
and I have to run
orignal
talk later
zzz
ok, good meeting, later
zzz
thanks zlatinb will take a look tomorrow