@eyedeekay
+R4SAS
+RN
+T3s|4
+acetone
+orignal
+weko
Irc2PGuest39199
Leopold
Minogami
Onn4l7h
Onn4|7h
ProRu
T3s|4__
anon3
eyedeekay_bnc
j6
not_bob_afk
profetikla
qend-irc2p_
x74a6
zer0bitz
orignal
can a range be 0 0 ?
zzz
no
orignal
why?
orignal
let me explain my problem
zzz
no point, and that's what the spec says
orignal
I need to resend a packet and and to replace Ack block to current one
orignal
but current block is shorter
zzz
"Range nack and ack may not both be zero"
orignal
and I can't insert padding block in the middle
zzz
how about put ack block after the data and then make the padding block bigger if the ack block gets shorter?
orignal
I don't want to move data block
orignal
ofc I can move it
orignal
but was looking for a simplier solution
zzz
because an ack block could also get longer than before, so that gives you the most flexibility
zzz
yeah that's what I recommend. I put ack after data, because it's easier to calculate how much room is left for acks
zzz
nope, I;m wrong, I do put acks first
orignal
yes, I though Ack block must be first
orignal
if new ack block is longer it's not a problem we can shrink it
zzz
I don't think there's any ordering requirement for ack blocks
orignal
btw, what's wrong with padding block in the middle
orignal
in finance they do it all the time
orignal
like few paddings in a message
zzz
I guess the idea was to not waste time processing the padding until the end. We put that in for NTCP2
zzz
but you're right its not really a problem
zzz
I'm deep into research on path challenge/response and connection migration, and I'm going to have some recommendations soon
orignal
nice
orignal
I'm working on transmision window and RTO calculation now
zzz
great
orignal
that's was always the problem with SSU1 because it floods the network someimes
orignal
instead queueing up
zzz
yup
zzz
could be a lot of work and testing to get right... we've been working on it, off and on, for 5-10 years
zzz
my short recommendation for connection migration:
zzz
path challenge = PING
zzz
path response = PONG
zzz
implement the easy part (PONG) before the release, that will allow us to develop the hard part (PING and state management) after the release
orignal
I'm doing it the same way as I do for streaming
orignal
just tell me what to do with path challenge block and I will do
zzz
great, thinking through it and documenting it now. As usual, QUIC has good guidance but it's overly complex, trying to make it more simple and sane
zzz
I'm seeing a port change on SSU1 like once a minute across a thousand sessions, and I don't handle IP changes at all
zzz
added some logging to see if it ever happens on SSU2, nothing so far
orignal
symmetric NAT?
zzz
not sure if that's the right term, but the port mapping in the NAT times out, and so then another packet goes through, and it comes out on a different port than before
zzz
we try to ping frequently if we think we're natted, to keep the same mapping, but sometimes the timeouts are really short
zzz
and of course I don't know what i2pd does about it
orignal
i2pd recognizes by endpoint in SSU1
orignal
but in SSU2 we use ConnID
orignal
and that's right I should update endpoint when it changes
zzz
Migrate! 61 byte packet from 192.181.7.4:16130 for 192.181.7.4:61638 lEKIIc
zzz
first one to hit my log
orignal
what's that?
zzz
SSU2 router that changed port
orignal
what is in RI?
zzz
firewalled
orignal
Java?
zzz
yes
orignal
it's clear why it's firewalled
orignal
becuse it still believed it's 16130
zzz
actually other way around. started as 61638, then I got the packet from 16130
orignal
I'm wondering what was in peer test
zzz
found a i2pd router with a route48 address and a 1280 advertised MTU
orignal
what was the prefix?