#ls2 (irc2p) | #ls2 Proposal 168 review here 8 PM UTC Tues. Dec. 3

zzz happen to have PacketBuilder2 logging on WARN or better? if so you should have a WARN message starting with "Size is" just before the error, that would help

dr|z3d unfortunately not, but let me enable that now. router wasn't logging much at all, default ERROR level.

dr|z3d ok, 4 ssu2 classes setup as warn level.

zzz rats, but ok, trap is set for next time

dr|z3d yeah, very rare that one, only seen it once on one router as yet.

zzz note that you'll get "Size is" msgs without the subsequent error too, those are fine

dr|z3d ok

zzz orignal, I see a couple of i2pd routers with IPv4 MTU now, so it looks like you have that fixed

orignal no

zzz no?

orignal you only see it if local address is specified explicily

zzz ok, got it

orignal I still don't have a code to find it

orignal due the NAT

zzz just reporting what I see, didn't understand the details

orignal I know, just explaining what's this

zzz :)

orignal another "bind" thing

orignal but strange that people bind ipv4

orignal it's usually v6

dr|z3d I'm getting a lot of ".PeerState2: ACKed but not found in outbound messages" warnings.. I guess that's nothing unusual, zzz?

zzz yeah thats fine

zzz but should be rare?

dr|z3d 5 in the last 1/2 hour

dr|z3d and ongoing.. seems to be fairly regular.

zzz I have 120 in 17 days

dr|z3d ok, I'll keep an eye on it.

orignal 12:25:15@683/debug - SSU2: Block type 4 of size 1138

orignal 12:25:15@683/debug - SSU2: First fragment

orignal 12:25:15@683/debug - SSU2: Block type 5 of size 989

orignal 12:25:15@683/debug - SSU2: Follow-on fragment

orignal nice split

orignal found the issue with duplicated session

R4SAS I'll update my routers part by part now

R4SAS with sessions fix

orignal and with windows

zzz great, thanks. I'm testing my fixes on my side

R4SAS I see bunch of transit now on ssu2-only router

orignal because I have made resend interval 10 times less then before ))

zzz your retransmission timer?

orignal yes, 300 ms

orignal but now I will use calculated RTO

orignal 300 ms for first reatrans ofc

orignal then it's gorwing

zzz I'll give you ours:

zzz min(1000, max(60000, RTT + 4*RTTdev))

orignal why 1000?

zzz w/ exponential backoff

orignal yes the same

orignal but why 1000?

zzz will research and get back to you, gotta run

orignal in my opinion if your RTT is more than 300 you shouldn't mantain this ession

orignal session

orignal remeber RTT between Toronro and Chicago is 6 ms

orignal hence 1000 is extremely high

zzz yeah sounds high to me also. But remember it's measured RTT, which includes both real RTT, queueing time, CPU time, delayed ack, ...

zzz but I'll figure out how we got here and what QUIC recommends

orignal you know I limit client tunnels by 250 ms per hop

orignal if exceed I exclude such tunnels

zzz ok we went from 250 to 1000 min. in Feb 2019, ref: trac ticket #2443. I'm sure zlatinb was involved

zzz QUIC minimum is 1 ms

zzz our streaming minimum is 100 ms

zzz i doubt I can find the trac ticket but the title is "Make SSU compliant with RFC 6298"

zzz (2.4) Whenever RTO is computed, if it is less than 1 second, then the

zzz RTO SHOULD be rounded up to 1 second.

zlatinb yes

zzz Traditionally, TCP implementations use coarse grain clocks to

zzz measure the RTT and trigger the RTO, which imposes a large

zzz minimum value on the RTO. Research suggests that a large

zzz minimum RTO is needed to keep TCP conservative and avoid

zzz spurious retransmissions [AP99]. Therefore, this specification

zzz requires a large minimum RTO as a conservative approach, while

zzz at the same time acknowledging that at some future point,

zzz research may show that a smaller minimum RTO is acceptable or

zzz superior.

zzz and here's the AP99 reference:

zzz ntrs.nasa.gov/api/citations/20000004338/downloads/20000004338.pdf

orignal I will try

zzz zlatinb, do you recall why you considered RFC 6298 as the gold standard as opposed to some other recommendation?

zlatinb it contained the most detailed description of the calculations to my knowledge

zlatinb not just the min RTO but the whole computation

zzz the document says it's conservative, and clearly it is, but that doesn't mean it's wrong. interesting though that our end-to-end streaming protcol has a 10x smaller minimum

zzz orignal, here's what I see for measured SSU RTTs on two boxes:

zzz box 1 (hosted): min 3ms, max 4sec, median ~110ms

zzz box 2 (home): min 43ms, max 689ms, median ~175ms

zzz orignal, the analysis, of course, must be based on efficiency, i.e. % retransmissions. What's your retransmission rate before and after the change?

zzz for me: box 1: 1.6%; box 2: 6.5%

zzz a lot higher than I would have guessed

zzz not sure if an average across all conns is the best metric though

dr|z3d looks like another part tunnel spike is in progress

zzz yeah I've been keeping an eye on things. we are going into the weekend, with higher traffic in general, but that's also when the last big event was

dr|z3d yeah, this is definitely an abnormal spike, the second obvious one today, but less pronounced than previously.

R4SAS testing now 0-0/1-1 tunnel (server/client) with ssu2

R4SAS 1.2 MB/s in peak