zzz
0) Hi
zzz
hi
orignal
hi
eyedeekay
hi
zzz
zlatinb_ is on the road
zzz
happy monday
zzz
what's on the agenda for today?
eyedeekay
I've got a go-i2p update(no copypasta this time)
orignal
I have an issue with SSU2 termination reasons
orignal
it must be clrified
zzz
ok. go-i2p is 1)
zzz
2) is SSU2 termination reasons
zzz
1) go-i2p
zzz
"go" ahead eyedeekay
orignal
3. mtu detection
zzz
ok 3) is MTU
eyedeekay
Took one of the suggestions from last week, to start with plain Noise and mod on top of it
eyedeekay
So this week I tried implementing an unmodified Noise transport for I2P
eyedeekay
Got pretty far with it but not quite done yet, right now it will set up a transport muxer, then a transport which is basically a session muxer, and a session which actually establishes the connections and does communication
eyedeekay
It will be inoperable in the final implementation ofc
zzz
sounds like drama-free progress
eyedeekay
But for now I think it's useful for testing the transport interfaces, which I think may have some shortcomings which will be my agenda this week
eyedeekay
In lieu of copypasta I'm posting my notes here in the root of the repo, did it today this time but I'll do it as-I-Go next week: git.idk.i2p/idk/go-i2p/-/blob/master/PASTA.md
eyedeekay
Yeah it's been a quiet and steady thing this week
zzz
I suggest you put that link in the thread on my forum, as bait to attract more help
eyedeekay
Will do
zzz
thanks for the update, anything else on 1) ?
orignal
no
eyedeekay
Nope
zzz
great
zzz
2) SSU2 termination reasons
orignal
we should exclude code that don't make snse
orignal
especially about SessionConfirmed
zzz
we already have the note:
zzz
Not all reasons may actually be used, implementation dependent. Most failures will generally result in the message being dropped, not a termination. See notes in handshake message sections above. Additional reasons listed are for consistency, logging, debugging, or if policy changes.
orignal
I think we should removes those that can never be used
zzz
we could, for example, send termination for session confirmed errors later
orignal
no way you can do it
orignal
because you need to handle it without error
zzz
like the way I do it: look for the v4/v6 address, get the i and the s, and if the s is a mismatch, I _could_ send a termination
orignal
then it must be another tremination reason
zzz
you want to make a list of the ones to be removed?
orignal
like "unsupprted adddress" etc.
orignal
yes
orignal
I will do
orignal
also I think "timeout" is not good for all reasons
zzz
ok, then I'll remove them, we can always put something back later
orignal
because there are different cases
orignal
you might not recieve an ack for signle message
orignal
your message queue is too big
orignal
simply means narrow channel
orignal
or you see too many gaps in received messages
orignal
and you send timeout for all of this
zzz
sure, but for most reasons, it's just for debugging. We don't really do anything when receiving a reason, except for maybe clock skew or banned
zzz
so it's not really important to have super-exact reasons
orignal
we don't do it now
orignal
but can be used for profiling later
zzz
I'm happy to add more, it's not a problem, more numbers are free :)
orignal
complete outage and just narrow channels are two differenmt rpoblems
orignal
let me prepare an updated list
zzz
great. let's not renumber anything though
orignal
I will prepare just a list without numeric vlaues
zzz
ok
zzz
anything else on 2) ?
orignal
no
zzz
3) MTU
orignal
so I remebered why I don't publish mtu for ipv4
orignal
because your local interface is usually 192.168.x.x
orignal
not an external address
orignal
so how are we supposed to detect MTU if local interface is not specified explicitly?
zzz
usually
orignal
that's why I do it for ipv6 only
zzz
well, even 192.x could be tunneled over ipv6, with a lower mtu
zzz
or vpn
orignal
yes
orignal
so I mean I usually don't know my local address
zzz
so you should still detect it
orignal
and my socked is bing to 0.0.0.0
orignal
*bind
orignal
do you have an idea?
orignal
for ipv6 is simple
orignal
I take an extrenal address and find local interface with it
zzz
go through your list of interfaces. pick the one that's not 127.x
zzz
if you're behind a firewall, you probably have only one
orignal
what if I have LAN and VPN tunnel?
zzz
if you have a publicly routable address, pick that one. If not, pick a non-routable but non-localhost address
orignal
fine, it's not a bad idea
orignal
it's for ipv4
zzz
you can do the same thing for ipv6
orignal
I might have few address from global scope easily
orignal
well I bind explicitly in this case
orignal
let me see
zzz
sure, you just have to classify and sort them into global/dynamic/temporary/deprecated, that takes more work
orignal
yes
orignal
time to start doing it
zzz
I have code to read the flags from /proc on linux and fallback heuristics for windows if you want to steal it
orignal
because ipv4 mtu is always 1500 now
orignal
thanks. but let me looks at our
orignal
since we go through the list of interfaces anyway
zzz
ok
orignal
android is another pain
zzz
can I give my status on MTU?
orignal
yes
orignal
tell me
orignal
seems MTU was the source of failures
zzz
so, I changed my code to limit session confirmed fragment size to 1280, no matter what the MTU says
zzz
as a test
zzz
a couple of days ago
zzz
it seems to be helping a little? not sure
orignal
fragment or MTU?
zzz
packet size = MTU
zzz
and then I also start the data phase at 1280
orignal
see, when me, R4SAS and Orion started publishing correct MTU no more failures
orignal
you said fragment not packet size
zzz
Orion is confusing to me. I thought it was 1420 on the router and 1500 on the PC
orignal
you 1280 is fragment of packet size?
zzz
yeah I said it wrong
zzz
packet size
orignal
he had 1280 on router by mistake
orignal
then he changed to 1480
orignal
on router
orignal
and 1500 on PC
zzz
oh ok. I know you talked a lot more with him, I didn't get the translation
orignal
1420 is his another router
orignal
well he doesn't speak English ))
orignal
and his is not THAT Oriin ))
zzz
that's fine. I didn't ask you for a summary either.
orignal
I mean i2pcpp guy
zzz
so now he's publishing 1480
zzz
yeah I know
orignal
yes, and has 1480 on router
orignal
no, we asked him explicitly
orignal
when he first appeared there
zzz
and I don't see any more errors with him
orignal
yes, that's what I mean
orignal
MTU is veru importnat
orignal
and I can't imagine how many failures we have with SSU1
zzz
yup
zzz
here's my errors last 30 hours
zzz
15 sQ8dVd
zzz
15 ~GIB3b
zzz
5 p~8-FO
zzz
4 bAU~6X
zzz
3 k8vhnd
zzz
2 1HmrG9
zzz
1 PCKdUl
zzz
1 oBZUnh
zzz
1 Cznve~
zzz
1 bOVM-F
zzz
this is with a 1280 initial MTU
zzz
I think the ones at the top can't handle fragments at all
orignal
I think they run very old version
zzz
I'm continuing to investigate handshake failures of all types
zzz
I'm looking at cases where the session created is retransmitted multiple times
orignal
and you don't see any of mines in this list
zzz
I'm playing with retransmission timers and timeouts
zzz
so I'm not ready to recommend 1280 for session confirmed. Maybe it will help, maybe not. It's still not clear how much PMTU issues there are out there
orignal
I don't think it will help
orignal
and you can detect your MTU by that time
orignal
because SessionCreated comes first
zzz
we still have a PMTU detection algorithm in java code, for SSU 1 and 2, that adjusts up and down
zzz
so I'm watching it to see how it does
zzz
in SSU 1, remember, we actually start at 620 (!) and go up from there
orignal
yes it's a next step
zzz
I looked at QUIC docs.
orignal
sec. phone call
zzz
they say don't use a MTU unless you "know" it will work, but don't really say how
zzz
except for "Path Challenge". Before you use, say, 1400 MTU, you send a 1400 byte "path challenge" and wait for it to be acked
zzz
eyedeekay, stuff like MTU is why NTCP2 is easier :)
orignal
btw what is Path challenge for?
orignal
and how does it help me to detect mtu?
zzz
it's dual use. for 1) to validate other guy's IP if it changes; 2) to test a big packet before increasing MTU
zzz
so, before sending data with X MTU, send a Path Challenge with X MTU and see if it gets acked
orignal
so it's like echo?
orignal
should I ack a packet with path challenge in it?
zzz
we haven't talked about it, unimplemented, and not fully specified in the proposal
zzz
might just be a waste of bandwidth
orignal
just telll me if I have to ack it
zzz
lol we'll decide together, not today :)
orignal
no I don't think it a waste of bandwidth
orignal
for now I only ack I2NP and fragments
zzz
if we don't think PMTU is a problem, we don't need it. If we can just do it with data, we don't need it
zzz
peer test and relay are also ack-eliciting
orignal
really?
zzz
yup
orignal
do you resend them?
zzz
not yet
orignal
thanks for letting know I will add them to acks
orignal
good finding
zzz
actually, everything is ack-eliciting except for padding and termination. and we haven't decided about termination yet
zzz
oh, and of course ack block is not ack-eliciting
orignal
and other ack
orignal
I though we might ack tremination with "termination received"
orignal
and it's not an ack
zzz
yeah there's three choices:
zzz
1) do nothing
zzz
2) send an ack
zzz
3) send termination with 'termination received'
orignal
I just do 1
zzz
I haven't really thought through it yet. Do you have a recommendation?
orignal
e.g. terminate session
orignal
not sure yet
orignal
I think it's the same problem as in streaming
zzz
right, I do 1) also, for 17 years
zzz
no, in streaming I keep a list of 'recently closed' connections and respond with reset or another close or something, can't remember
zzz
that's pretty much what the QUIC recommendation is
zzz
ok, let's not forget about this issue, I'll put it on the list for next week
orignal
yes
zzz
anything else on 3) ?
orignal
no
zzz
anything else for the meeting?
orignal
we are very close to working SSU2
eyedeekay
Nothing else from me
zzz
it definitely works. we're trying to get it to work every time :)
orignal
not yet from my side
orignal
still no introducers
orignal
although I'm able to connect to your firewalled router after first attempt
zzz
eyedeekay, when you headed to NY?
zzz
let's make sure the handshake works every time, even with retransmissions, and the acks/nacks work right
orignal
btw, do you think it's possible to have more than 2 fragments for SessionConfirmed?
eyedeekay
On the road Thursday
eyedeekay
Should be there by Friday
zzz
even at 1280, 2 is probably enough with gzip, but I haven't done the math to know for sure
orignal
it might be 480 for ipv4?
orignal
I saw this value in the code
orignal
int fallback = localAddress.is_v6 () ? 1280 : 620; // fallback MTU
orignal
620
zzz
yes, that's the spec, 620
zzz
which is insane, but that's what we do
zzz
for SSU 1
zzz
that's why SSU2 is 1280. to not be insane ))
zzz
so if you see a IPv4 interface MTU < 1280, do not enable SSU2
orignal
fine
orignal
let's asumme 1280 min
zzz
yes, that's the spec, same as QUIC
orignal
do you attach Ack block to PeerTest msg 6 for msg 5?
zzz
no, msgs 5-7 are not in session, so ack blocks don't make any sense for them
orignal
so you don't resend them?
orignal
fine
zzz
I can't remember. they are resent in SSU 1, not sure about SSU 2
orignal
doesn't make sense to resend 5
orignal
because it's fine if it's not received
zzz
that sounds right