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

orignal but I don't know how to fix

orignal if NACKS > 255

orignal that what happens

orignal add range 255 0?

zzz yes

zzz but that didn't happen here

orignal I know what happened there

orignal now I'm asking about more generic case

orignal to avoid zero acnt in future

orignal want to rewrite that code

zzz yup

orignal I don't produces ranges 255 0 and 0 255 yet

orignal fixing it now

orignal fixed

zzz happened again, 10 minutes ago, with 2RRY - no ack of session confirmed, no ack of any packets

orignal I haven't fixed for SessionConfirmed yet

orignal SSU2: Unexpected message type 168 from [2a02:180:2:92:92:92:11:15]:16799

orignal looks like it was mass outage on ipv6

zzz ok

zzz got some fixes to do on my side too

orignal do you know is there are similar issue for SSU1?

orignal because I use the same sending code

zzz not sure

orignal I mean if I sent a datagram and there was not error

orignal what else I can do?

zzz if the internet drops everything for 10 seconds, there's not a lot to do

orignal not sure if it was everything or just UDP

orignal coz send buffer overflow

orignal maybe we can check it and queue it up, etc.

orignal I will add the code to check actual sent size

zzz count of session confirmed retransmissions by router, last 24 hours, highest ones:

zzz 67 tXc6dH

zzz 49 k8vhnd

zzz 49 BpATV4

zzz 41 kyY2Tx

zzz 28 3PYq0v

zzz 19 YXEAXl

zzz 18 bAU~6X

zzz 16 CEFnjX

zzz 14 xZ9nsA

zzz 12 2RRYXk

zzz 9 ImQCa~

zzz all i2pd

orignal I know because it's not implemneted

orignal will fix today

orignal btw, you don't receive more SessionCreated from me

zzz huh?

orignal you restransmit sessionconfrimed

zzz right

zzz just typing out the scenarios for my own sanity:

orignal I'm wordiring if I have received it

orignal if I didn't I would keep seinding sessioncreated

zzz when I'm retransmitting session confirmed, I'm also retransmitting one or more i2np messages

zzz so there's two cases:

zzz 1) you didn't get the first session confirmed. when you get the retx, send ack 0, and decrypt the data packets if you queued them, and ack them

zzz 2) you did get the first session confirmed. you won't be able to retransmit the retransmitted session confirmed,

zzz *you won't be able to decrypt the retransmitted session confirmed,

zzz but you will be able to decrypt the retransmitted data packets, so send ACK 2-0, 3-0, 4-0, or whatever for each data packet you get

zzz that will ack both the session confirmed and the data packets

zzz so both scenarios will result in bob sending an ack each time he gets something

zzz so you shouldn't need to resend ack 0 if you get 'garbage' (retransmitted session confirmed). You can if you want I guess (I don't)

orignal I will fix 2

orignal and send ack again

orignal but my question is why whole communication gets stuck

orignal so the problem is that I don't send ack even to data packet

zzz right. no idea why. I keep sending stuff, never get anything back

zzz this is the one problem with XK that's a little tricky to handle. IK doesn't have this issue

orignal and you are saying that you never send sessionconfirmed retransmission to Java routers?

zzz not saying that. The vast majority and all the top ones are to i2pd. Don't have an exact count but about 335 out of 350 total retransmissions in last 24 hours were to i2pd

orignal maybe because it was a spike in SSU1?

orignal since I don't control flow there

orignal it might be flood of UDP packets

zzz no ideas here, sorry

orignal I don't see R4SAS's SSU2 only routers here

orignal that's why

orignal I meant in your list

zzz here's the rest of the list, fyi:

zzz 5 OANQwi

zzz 5 nYlJtl

zzz 4 Qreu1M

zzz 4 PeGQYG

zzz 4 p~8-FO

zzz 4 MNcWgU

zzz 4 jGiQZ8

zzz 4 iNmqNX

zzz 4 gpUBQf

zzz 2 -Ym2vN

orignal his is gpUBQf

zzz yup

orignal maybe that's the reason

zzz if you're overflowing some queue you would log it, right?

orignal how is it possible?

orignal you send an UDP packet and system or routers just drop it

zzz I'm not going to make guesses about your code

orignal for example at works we use different VLANs for multicast

orignal on different nteowrk cards

orignal it's not about my code

orignal it's generic UDP

orignal no delays and no error even if a packet gets dropped

zzz but this is over at least 10 seconds. I'm sending the data packet 4 times at 0, 1, 3, 7 seconds and timing out at 10

zzz and never get an ack

R4SAS zzz: can you print all incoming packets to socket?

R4SAS orignal: and you all sending

zzz so I've sent session confirmed 4 or 5 times (packet 0) and (at least) data packets 1-4

zlatinb testnet + wireshark time :)

zzz R4SAS, see scrollback, 16:14 eastern (UTC - 4) yesterday, for an example

R4SAS zzz: this is parsed messages

R4SAS I'm about raw packets with only "SRCIP, seq N, DSTIP"

zzz not necessary yet. I'm waiting to hear if i2pd _did_ get the 4 data packets and _did_ send an ack for each

R4SAS same thing I proposing for orignal but for outgoing packets

R4SAS to see if ACKs really sent

R4SAS zlatinb: if u can, that would help

zlatinb when my hand heals I can look into it

zzz it would be tough to reproduce on testnet, because testnet routers like to connect once and stay connected

zzz not the best way to find intermittent handshake issues

orignal there is no such thing as "really sent"

zzz sure

zzz 0) Hi

zzz hi

orignal zzz, i2pd definetly sent acks to data packets

orignal and didn't send to sessionconformed retrans

eyedeekay hi

orignal hi

R4SAS hi

zzz but I mean in this case where I've given you a timestamp

zzz what's on the agenda for today after a week off?

eyedeekay I have a go-i2p report

orignal nice

orignal SSU2 status

zzz ok go-i2p will be 1), and SSU2 will be 2)

zzz anything else for the list?

zzz ok then

zzz 1) go-i2p

zzz what's the latest?

eyedeekay Beware of copypasta

eyedeekay I am cautiously approaching sending my first SessionRequest message

eyedeekay The KDF documentation was very helpful this week, what I worked on mostly was KDF for handshake message 1, that section of pseudo-code

eyedeekay I need to fit the message-1 KDF stuff I'm working on into the go Noise library I'm tentatively using: github.com/flynn/noise which is what I'm figuring out now-ish

eyedeekay Which I think I can by implementing alternate versions of the library's interfaces rather than needing to do it all

eyedeekay But if that turns out to be outside the capabilities of the library at this time, I'll fork it and see if the upstream is interested in my changes, and if not, I'll need to re-evaluate and pick a different one, maintain a fork, or write my own.

eyedeekay First time is going to be the hardest time with that, once I know how to customize my Noise library adequately doing other protocols will be more like varying a theme

eyedeekay Once I figure out how to do that, I'm pretty sure I can construct a SessionRequest message, connect to to a router, send it, then probably have something on the go-i2p side explode, because it won't know what to do next yet with what it gets back

eyedeekay but if I can read response bytes from Bob after sending the SessionRequest, then I will have officially made a network connection to another I2P router and sent it a message it can hopefully understand, which feels significant

eyedeekay I hope to attempt that by Friday after getting the KDF implemented

eyedeekay With all that I'm going to also push a roadmap for NTCP2 to go-i2p/transports/ntcp/README.md to outline the rest of the stuff that I think will need to be done before it's implementation-complete

eyedeekay Feeling semi-optimistic regarding time, optimistically between 1-2 months for it to reach the Data Phase

eyedeekay There are, I think, some changes I'll need to reach back into the common library to update Router Info's to publish NTCP2 addresses too

eyedeekay It's all a big mess right now with unused versions of functions commented out and notes on why they didn't work, though, I'll have to get rid of most of that before I check anything in

eyedeekay EOT

zzz yeah the trick is the mods you'll need for our AES-obfuscation

zzz and padding

eyedeekay Yeah I'm beginning to get that, that's where I think I might need to make changes upstream to flynn/noise

eyedeekay It's a little confusing

eyedeekay But I'm getting my head around it gradually

orignal is it NTCP2?

zzz the way it usually goes when first testing a handshake is that you'll get nothing back because it's not right

zzz so then, maybe, java-side logging will give you a clue

eyedeekay That's also a possibility :)

zzz but in practice, the next step is probably to write both sides (alice and bob) for session request, and do a unit test

zzz once that works, then try again vs. java

zzz so, if you're lucky, you'll get something back, but don't count on it

eyedeekay Probably won't but I'm going to give it a try with a router on my LAN as soon as it's a possibility

eyedeekay Interesting either way

zzz sounds like great progress

eyedeekay orignal yes I'm starting with NTCP2, unless I have a good reason otherwise I'm probably not going to do NTCP1

zzz holler if you need help

zzz NTCP1 is definitely dead

eyedeekay Yeah it's finally getting to the point where it's actually going to do something

orignal or you might start witj SSU2

orignal and will be on the same page with us

R4SAS )))

eyedeekay Right now my immediate hurdle is figuring out how to mod noise

zzz we've been over this many times. SSU2 is at least 3-4x more complex than NTCP2

orignal I even don;t have NTCP1 code in i2pd anymore

eyedeekay Like I said, I probably won't do NTCP1, certainly won't make it a priority

zzz with a unit test you can try it without mods, then add the mods one by one

orignal and you shouldn't do it at all

eyedeekay That's a good point, I can start by testing the mods one-by-one if I test them as I add them

eyedeekay Trying to get things done all-at-once has held me back here before

eyedeekay So that's probably a good idea

zzz but always fun to test in the live net, in the unlikely event that it works, you've avoided a lot of unit testing. It just usually doesn't happen like that

eyedeekay Well either way, learning and progress, that's why I'm doing it

zzz yup

zzz anything else on 1) ?

eyedeekay Not yet

eyedeekay next week

zzz definitely the most progress ever reported, very nice

zzz also, a good thread over on zzz.i2p about use cases

zzz 2) SSU2 status

zzz who wants to go first? I forget whose turn it is

orignal idk

zzz ok, I'll go

zzz found and fixed a nasty bug yesterday where I was treating NACKs as ACKs

zzz my main priority is getting rid of all packet loss (except for normal packet loss)

orignal and found a bug for me

zzz so if I can see a pattern, there's something wrong

zzz I see two main causes right now, both when talking to i2pd:

zzz 1) no acks at all for outbound connections, as discussed above

orignal I think not only outbound

zzz 2) no termination received, I send something after i2pd has timed out

orignal it can happen with any connection

zzz ok

orignal about 2 I have made some changes

zzz I'm continuing to see longer session uptimes, and more traffic, and more routers

orignal you should see more termination blocks

orignal also with reason code

zzz I don't _think_ there's any more relay or peer test issues, but I'm not looking for them right now. I'm focused on making basic data traffic be 100% solid

orignal so, my turn I guess?

zzz EOT, go ahead

orignal let's start with relay and peer test

orignal for me it's higher priority than basic traffic because I can't replace SSU1 by SSU2 without it

orignal after recent bug fixes peer test and relay requests work good

orignal still working on Charlie's side e.g. being firewalled

orignal you mentioned another bug with Acks

orignal that my Ack block always keep growing

orignal because there are gaps in received packed, and some messages never retramsmitted

zzz hmm. you don't "trim" it?

orignal I do

orignal but I need to do it more

orignal also I never sent ranges more than 255 acks or nacks

orignal I need to add few ranges

orignal that I have fixed yesteraday

zzz yeah that one I posted yesterday was 605 all the way down to 0

orignal yes because too many ranges

orignal but it might be possisibility that not too many ranges but each range is big

orignal and I need to clean up older our or sequence messages

orignal I was going to do it today but didn't have time yet

zzz fyi right now my max is 512, and I shift up by 128. So I'll cover at least 384

orignal I was going to start with 1K

orignal or 2K

zzz really depends on max window

orignal e.g. difference between last received seqn and seqn of first gap

zzz but retransmissions are new pkt numbers so it has to be a multiple

orignal yes, that's another issue

zzz the right answer is probably somewhere between 256 and 2K

orignal that's what I'm going to do

orignal the problem is that 2K might come in very short time

orignal less then a second

orignal that's my main concern

zzz sure but doesn't matter how fast, the issue is how big your window can get and how often you're acking

zzz and what the other guy is doing

zzz any other SSU2 status?

orignal yes

orignal so back to issue 1

zzz go ahead

orignal I start suspecting that SSU1 causes it

orignal but need to investigate more

zzz sure, always good to have a theory. then try to prove it true or false

orignal based on my experience if you pump to many UDP packets through the same interface they get dropped

orignal that's why I want to switch to SSU2 insted SSU1 soon

zzz can't switch until it works :)

orignal because SSU1 trafiic is really untrolled

orignal not true

zzz I'll just keep reporting what I see

orignal if you SSU2 doesn't work, SSU1 doesn't work too

orignal *say

orignal I mean even bad working SSU2 is better that SSU1 in i2pd

zzz maybe, maybe not. we don't have any data on packet loss in 1 vs. 2 for i2pd

orignal I kno it's a lot

orignal I didn't fix it assuming we were going to start working on SSU2 anyway

zzz I'm working on changes to temporarily ban routers that have failures like 1) and 2) above

orignal what do you see about 2) now?

zzz I close the session but it's not banned

zzz so we usually just open a new session almost right away

orignal as I said I send termination now

zzz ok I'll look for termination in the logs, please ask everybody to update

zzz any other SSU2 status?

orignal they keeps updating anyway

orignal you should see improvements

orignal at least with my and R4SAS 's routers

orignal no

orignal another thing is mtu

orignal haven't decided about SSU2 over yggdrasil yet

zzz yes, MTU is part of the "basics"

orignal with 64K MTU

orignal I will implement it soon

orignal but 64K is different story

zzz you should be getting full 1500-byte packets from java routers, at least sometimes

orignal yes I assume it might up to 1500

zzz and never 1501+ :)

zzz anything else for the meeting?

orignal 64K might change the picture dramatically

orignal no

zzz anybody else have anything more?

zzz ok, I guess that's it, thanks everybody

orignal I would recommend idk to work in parralel on NTCP2 and SSU2

orignal because too much common code and approaches

eyedeekay I get the point of what you're saying there orignal, since zzz did describe SSU2 once to us as NTCP2 over UDP with some QUIC features, but for better or worse I'm going to stick to NTCP2 for now, if there's code I should be sharing between the transports I'll just have to refactor it when I reach that point

orignal eyedeekay for example block

orignal they work same way

orignal handshake and Noise states

orignal if I start implemnting now

orignal I would implemente common code for it

eyedeekay OK now I really do see your point

orignal but NTCP2 was implemneted few years ago

eyedeekay My problem is that I don't fully know which parts would end up common and which parts would end up specific yet

eyedeekay You've given me some clues just now though, block, handshake, and noise states

eyedeekay So I can maybe plan for that

orignal blocks, Noise are common

zzz sure, wouldn't hurt to skim the SSU2 spec to get a sense of what's common

orignal SessionRequest-SessionCreated-SessionConfirmed

zzz they're both XK

orignal Bob doesn't know whohe is talking to because SessionConfirmed

orignal and there he verify S instead signatures

eyedeekay This is good, it seems like since I'm working on modding noise and maybe sending messages now, now is the time to consider where this goes

zzz but I would come at it from the other direction. Not what is common at the low-level (blocks, noise, ...) but what are the common interfaces for a generic transport (send I2NP, receive I2NP, ...) and design your first transport accordingly, so it's not a mess when you add a 2nd one

zzz more succinctly: interface design >>> design for reuse

orignal also think about both ipv4 and ipv6 at the same time

eyedeekay psi stubbed out a transport interface years ago, there is a Transport interface with a sort of "session factory" which makes TransportSessions which are specified read, send, and queue functions

eyedeekay Being slightly agnostic of what I should do, that is part of what I'm working from at the moment

zzz eyedeekay, rereading your status above:

eyedeekay Right now I've made messages a simple interface and made each message an implementation of that interface, SessionRequest is just the one that I've made the most progress on

eyedeekay but I've put them inside of the same module as the NTCP2 transport, if I move them I can easily share that code between transports

eyedeekay I still don't want to do both at the same time but I can maybe plan ahead for some of this now that I know about it

zzz <eyedeekay> I need to fit the message-1 KDF stuff I'm working on into the go Noise library I'm tentatively using: github.com/flynn/noise which is what I'm figuring out now-ish

zzz the NTCP2 spec of message 1 KDF *is* Noise. there shouldn't be anything to "fit in"

eyedeekay Oh well then maybe I've wasted some time

eyedeekay Or maybe I implemented what I thought was different without knowing it...

eyedeekay OMG I made a "spec language" error, this is my mistake

zzz remember this was our first noise protocol. str4d said 'just say follow the noise spec', I wanted to document more so we understood it, and orignal wanted to do really low-level documentation. orignal won

eyedeekay That's pretty funny, well I guess I know a little more about noise now

zzz the AES obfuscation of the eph. keys is really a post-processing / pre-processing step

eyedeekay Ha... talk about doing things the hard way

zzz the one wrinkle is adding the padding, and for messages 2 and 3, is the mixHash(padding)

eyedeekay OK I'm just going to re-read some of these headlines here and take a moment to ask some questions

zzz I'm not sure what you're fitting into what. But glanced at the flynn lib doc and the terminology/naming is identical to the java noise lib we're using

eyedeekay Well I thought I was writing a KDF and implementing it to extend flynn/noise but since I didn't read "as defined in" correctly I think I was just re-writing an existing KDF

eyedeekay apparently I spent a lot of time on something because I was looking at the code block and not the sentence directly above it

eyedeekay Which explains why I couldn't figure out how to fit it in

zzz i2pd didn't use a noise lib, and we all dislike/hate the noise docs, those are the other reasons it's all "unrolled" in our spec

eyedeekay I get it now I think

zzz the "Additions to the Framework" section of the spec should be the full list of changes

eyedeekay So the modifications I would need to do are to fulfill things like the 16-byte option block non-noise payload random padding

zzz they're minor, targeted, specific changes required for our threat model

zzz right

eyedeekay I think that might make some of my problems into non-problems then

zzz everything else, your noise lib should do for you

eyedeekay Well crap. I think I need to regroup and figure out where I'm at, because apparently what I've done is implement a part of noise with a slightly different crypto library than the one that my noise lib used, thinking it was something I had to do

eyedeekay but since flynn/noise has it already then I'm probably not actually behind for it

eyedeekay So many things just fell into place, how to modify noise makes so much more sense now

zzz :) thus demonstrating the benefits of weekly status...

eyedeekay Indeed

zzz if you were psi, you'd be checking in a lot of f-bombs soon...

eyedeekay I'm relieved because I'm pretty sure life just got like, 60% easier for me at least, but I also think I have to delete a bunch of code

eyedeekay Glad I know now :)

zzz yeah, it's messy, because Noise is (and is documented as) a state machine, which is unlike any spec I've ever read before or since.

zzz our docs "unroll" that state machine into a more traditional protocol spec

eyedeekay Yeah it's different enough that I missed a lot of the relationship between the two specs until now

zzz thus making it possible to implement without ever looking at the Noise spec

zzz but it makes it a lot harder to map between the two flavors, which you need to do if you're using a lib

zzz since the go lib looks like it matches the java lib pretty closely, you should be able to get a lot of hints from the java code

zzz our java code to generate message 1 is OutboundNTCP2State.prepareOutbound(), all of 75 lines and could be half that

eyedeekay For me it's NewSessionRequest, I'll compare them