#saltr (irc2p) | I2P+ 2.7.0-11+ >> i2pplus.github.io | skank.i2p | git.skank.i2p | purokishi.i2p | vituperative.github.io/i2pchat | natter.i2p | notbob.i2p | ramble.i2p | shreddit.i2p | cake.i2p | /msg an op for voice

dr|z3d here you go, zzz, roadmap mods.. you only need to copy the <style> block and overwrite your current <style> block with it: cake.i2p/file/TDjsCosSkP_GurxlUNjOuUPX8XC3ozIHY8q5iCGMe_hFTqJHXFVX/zzz-plan.html

zzz thx for the pnuts

RN *** hands zzz an epi-pen ***

zzz orignal, re: multiple relay responses sent from bob to alice

zzz done some logging and looking

zzz what I see is i2pd 0.9.64 alice repeatedly sending me a relay request with same nonce, AFTER I've sent the relay response

zzz and forgotten about that nonce. so the next time I do it all again

zzz sample:

zzz 11/02 17:32:43.213 Receive relay request from 85.228.46.115:17214 j~EeS2

zzz 11/02 17:32:43.251 Got relay response 0 as bob, forward nonce 2863524794

zzz 11/02 17:32:43.328 Receive relay request from 85.228.46.115:17214 j~EeS2

zzz 11/02 17:32:43.373 Got relay response 0 as bob, forward nonce 2863524794

zzz 11/02 17:32:43.565 Receive relay request from 85.228.46.115:17214 j~EeS2

zzz 11/02 17:32:43.605 Got relay response 0 as bob, forward nonce 2863524794

zzz 11/02 17:32:43.885 Receive relay request from 85.228.46.115:17214 j~EeS2

zzz 11/02 17:32:43.924 Got relay response 0 as bob, forward nonce 2863524794

zzz 11/02 17:32:44.293 Receive relay request from 85.228.46.115:17214 j~EeS2

zzz 11/02 17:32:44.333 Got relay response 0 as bob, forward nonce 2863524794

zzz 11/02 17:32:44.830 Receive relay request from 85.228.46.115:17214 j~EeS2

zzz 11/02 17:32:44.869 Got relay response 0 as bob, forward nonce 2863524794

zzz 11/02 17:32:45.456 Receive relay request from 85.228.46.115:17214 j~EeS2

zzz 11/02 17:32:45.497 Got relay response 0 as bob, forward nonce 2863524794

zzz so I think I'm doing everything right, except maybe I should remember and ignore old nonces?

zzz but look at your 0.9.64 alice code

zzz I don't see any logs or code where I 'spontaneously' send a bunch of them

orignal so you respond to relay requests?

orignal thanks. will check

orignal do you send Ack to that relay request packet?

orignal for me it seems that retrans

orignal e.g. packet is not acked but you

orignal shoudl I set set "ack requested" in flags?

zzz no need to set flag

zzz yes we ack relay requests; even if we didn't send a separate ack, there would be in ack block in the relay response

orignal even if Data msg contains only relay request?

orignal I think that's the problem

zzz of course, we include ack blocks in every message

orignal the question is if even send it

orignal got it. it must be with relay response message

orignal let me investigate deeper

zzz this is a little confusing for sure

orignal but if it's Alice it's easy to reproduce

orignal the question is why I keep resending despite ack

orignal and strange that it doesn't happen with peer test

orignal althrough the same logic

zzz I'm not logging the timestamp in the request, I'll do that, that should tell us if it's a retransmission or a new one with the same nonce

orignal no doubts it's a restransimmission

orignal because I generate nonce randomly

orignal RAND_bytes ((uint8_t *)&nonce, 4);

orignal for every relay request

zzz ok

orignal when you receive replay request do you send ack right a way or with relay response received from Charlie?

zzz almost right away, delayed ~ RTT/6 which is way before the relay response usually

orignal so you don't wait for RelayResponse from Charlie

zzz correct

orignal let me investigate put some logging and see

zzz in the end I'll probably have to keep a recent relay request nonce list, because after I send the relay response I "forget" the nonce and can't recognize dups

zzz even if there's no bugs on either side, it can happen

orignal what is packet num is zero?

orignal most likely I send relay request as first message

orignal although it souldn't be

zzz checked a few dups, first one is #5 on one, #8 on another, #24 on another

orignal yes you are right I aslways recdeive Ack

dr|z3d zzz: got a question for you. can't find the search code for leasesets, want to do a partial search instead of searching for the entire b32. any ideas where the code is? :)

zzz same as for partial router hash. get them all, and iterate thru them

dr|z3d yeah, I just can't find where we're doing the ls/b32/hostname search. must be blind.

zzz sec

dr|z3d thanks

dr|z3d I figured it'd be useful to be able to input a partial b32 and get a result.

dr|z3d or a partial hostname for that matter.

zzz renderer.renderLeaseSet(Writer out, String hostname, boolean debug)

dr|z3d ok, thanks, I recognise that, it's in NetDbRenderer.

orignal hmm

orignal what I see all these relay reponses come in the same second

zzz you can see my timestamps in what I pasted above

orignal yes, you also send in the same second

orignal it seems my resend algoruthm

zzz only because the dup requests come in pretty quickly

orignal that's why it's definitly bug in my resend algorithm

zzz my min retransmission timeout is 1 second

zzz ok, you found something? good news

zzz I'm adding some logging and dup checks, will have results tomorrow

orignal not yet but it's clear that you send acks

zzz ok

orignal my retrans time is based on RTT

zzz don't forget you've also made a lot of changes since the release? easy to lose track of whats what

orignal see in case of I2NP you drop dupplicates

orignal I'm trying trunk

orignal and see bunch of RelayResponses

zzz yeah, for relay and peer test the dup checks have to be in the state machine because they don't have i2np message numbers

orignal will inverstiage why

orignal anyway we know the reason now

zzz normally I track dups but once I'm done with a test as Bob (when I send the relay response to alice), I delete all the state so I 'forget'

zzz so that's what I need to improve

zzz whether you have a bug or not...

zzz adding a LRU cache of nonces

orignal yes I delete nonce once I get reponse from Charlie too

orignal const int SSU2_RESEND_ATTEMPT_MIN_INTERVAL = 3; // in milliseconds

orignal ha ha

dr|z3d !!

orignal that's why

dr|z3d you probably meant 3*1000?

zzz yikes

dr|z3d we've found a network spammer..

orignal no. 3 ms

zzz long delta = Math.max(10, Math.min(_rtt/6, ACK_FREQUENCY));

dr|z3d no, I mean you *intended* 3*1000 when you wrote the code, but got it wrong.

orignal do you have a problem with SSU2 spam?

zzz rotected static final int ACK_FREQUENCY = 150;

not_bob hah

orignal 3 ms was intende3d

orignal it's just about initial resend interval

zzz oh wait that's the delayed ack calc... stand by...

orignal in reality it's based on RTO

RN *** does Pee Wee Herman impression "I meant to do that" ***

orignal americans who are you going to vote for Tuesday?

zzz private static final int MIN_RTO = 1000;

orignal I'm still checking

orignal definitly the problem come for very first message when no RTO yet

zzz private static final int INIT_RTO = 1000;

orignal const size_t SSU2_INITIAL_RTO = 540; // in milliseconds

orignal const size_t SSU2_MIN_RTO = 100; // in milliseconds

zzz I know you guys have been playing around a lot with rtt/rto/retx in streaming. I continue to recommend sticking exactly with RFC 6298 both for streaming and SSU2

orignal we diddn't changemuch in SSU2

zzz and that is referenced in the ssu2 spec

zzz 6298 specifies 1 sec min RTO (as a SHOULD)

dr|z3d what about for streaming?

dr|z3d private static final int INITIAL_RTO = 9000;

zzz same here

dr|z3d no, I know that's what you've got, I'm asking if it's due a revision. I've got 5000 right now.

dr|z3d just because 9000 seemed a bit high, but maybe it can go lower than 5?

orignal according to zzz's log my RTO is around 100 ms

orignal 100 after first, 200 after second, 300 after third etc.

orignal zzz, what's your ack interval? rtt/6?

orignal look like your ack is always late

orignal that's what happens

zzz long delta = Math.max(10, Math.min(_rtt/6, ACK_FREQUENCY));

zzz yeah. rtt/6, min 10, max 150

orignal what it will be if rtt is 100 ms?

zzz 100/6

zzz my median RTT is about 100

orignal but how do you know rtt at that moment?

orignal if it's first message came from me?

orignal you send Ack to my SessionConfirmed

zzz initial RTT is set during the handshake

orignal that I understand

orignal how?

orignal it's RTT + x25519 time

zzz by timing how long to get the handshake message back

orignal between wich messages if you are Bob?

orignal you send SessionCreated and wait SessionConfirmed?

zzz that sounds right, but I'd have to check

orignal the problem is x25519 round

zzz InboundEstablishState2.java: _rtt = (int) ( _context.clock().now() - _lastSend );

orignal on Alice side

zzz sure, it's not perfect, but it's a good place to start

orignal do you know how long x25519 is?

orignal I believe few millseconds at least

zzz no, but we have a queue of eph. keys precalculated, so that saves a little

zzz still better than just a constant. if the peer is slow doing DH, it's probably slow for other stuff

orignal ofc I mean x5519 shared key calculation

orignal my point is

zzz rtt is just an estimate anyway, not trying to be perfect

orignal what if your RTT is much higher than on my side

orignal say my RTT is based on RelayRequst->Ack

orignal so what was your ack delay time?

orignal 10 ms?

zzz yes

orignal should not be an issue than

orignal let me investigate deeper

zzz ok, afk, back tomorrow