#ls2 (irc2p) | #ls2 proposal review channel : Reviews Tuesdays 7 PM UTC: none scheduled

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?