#ls2 (irc2p) | #ls2 I2P Protocol Development Discussion - Next Meeting Monday, October 9th 6:30 UTC

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