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

orignal what is post termination hndler?

dr|z3d it's about 7 commits so far, orignal, starting with git.idk.i2p/i2p-hackers/i2p.i2p/-/commit/0fd6c672d35889112cf05647fc44e0b2975155b1

dr|z3d As for a succinct description, you'll have to wait for zzz for that :)

zzz handling packets received after a termination was sent or received, and possible termination retransmission

zzz see "Session Termination" -> "Data Phase" in our spec

zzz and QUIC RFC 9000 section 10.2.1

zzz I had nothing before

zzz so I didn't save any token received in the termination ack

orignal will check

zzz so this was necessary for me to stop sending tokens in the handshake, and only send them with termination

orignal so for new tokens

zzz yes, but also it's for sending another termination when we get a packet

zzz otherwise, if your termination got lost, the other guy could keep sending you I2NP for several minutes before he gives up, which is pretty bad

zzz so this was always on my todo list, but bumped it up after I saw how bad my token problems were

orignal that's how I do now

orignal if packets keep coming I send termintion

zzz yeah, you were ahead of me on that

zzz how long do you wait for more packets?

dr|z3d your SSU1 disablement stuff, zzz, still WIP or complete and ready for testing?

zzz dr|z3d, if you're not firewalled it should be good, I think I still have some peer test issues, which is why I haven't announced it yet on my forum

dr|z3d ok, thanks.

zzz I've been running it on one of my routers for a few days. Please report results

dr|z3d seeing a major drop in traffic or not so much?

zzz hard to say, this is my -Akx router with NTCP2 disabled too, and ipv6 force-firewalled, so not representative

dr|z3d ah. you're running your router in wheelchair mode. ok

zzz yeah, it's my ssu2 stress test router as far as config, but that config makes it not so popular

dr|z3d ok, will let you know how it behaves when I get around to enabling the config.

dr|z3d will test it on something pushing some packets, so I should be able to get some idea of the difference in overall throughput.

dr|z3d obviously this will be less and less relevant as the network migrates to the latest release. looks around 55% so far here.

zzz it's already preferred over ssu1, so the effect will be just to move conns with old routers from ssu1 to ntcp2.

zzz and very old routers won't talk to you at all

zzz so not sure what the throughput effects might be. probably not much

zzz what I'd be looking for is random NPEs or similar fails

zzz caused by 1 vs 2 confusion

dr|z3d ok, will keep an eye out.

zzz thanks

dr|z3d do you have any idea where we're setting the console/webapp cookies? those could do with tightening up a bit.

zzz how so?

dr|z3d getting console errors.. we should be setting those as same-site=strict and HttpOnly.

zzz I looked at that a while back

zzz it's deep in jetty

dr|z3d the other thing is the conflict between consoles. I wonder if we can't use the port to append something to JSESSIONID name to differentiate.

dr|z3d yeah, thought it might be jetty. couldn't see it in the source.

zzz the problem is jetty completely changed the API from 9 to 10, so it's almost impossible for us to do anything in a way that would work for both standard and debian

dr|z3d well, you say that..

zzz you mean http vs https?

dr|z3d I was thinking in the absence of anything better using javascript to manipulate cookies.

dr|z3d no, I mean 2 or more consoles with conflicting cookies.. local console, remote console 1 over ssh, remote 2 etc..

zzz ok, I looked at that a while back also

zzz because I hit it going back and forth between http and https on the same router

dr|z3d assuming the hostname's the same, eg localhost, then issue.

dr|z3d localhost and 127.0.0.1, no issue.

zzz the problem is that the cookie spec is port-independent. so it's unfixable

zzz use different hosts, like localhost, 127.0.0.1, [::1], etc. that fixes it

dr|z3d indeed

dr|z3d session storage might be something worth looking at for _some_ things. or local storage where persistence over router sessions is desirable.

dr|z3d if we could modify the cookie in transit, that would also work, append nonce or whatever to the cookie name. but I'm not sure that's possible.

dr|z3d what we should be able to do, regardless, is modify the cookie with javascript to add the same-site and httponly fields.

zzz both sound grim

dr|z3d ok, well, I guess it's not a major issue; if I get something working with javascript worth using, I'll let you know.

zzz ok I think i have termination retransmission working, going to watch it for an hour, that will be part 8

dr|z3d great stuff.

zzz yeah it's more important than I thought it would be, packet loss is real ))

zzz orignal, how long do you wait after termination for more packets?

orignal I don't have fixed time

orignal I consider that a session is over and clean it up next time

orignal I run cleanup every 30 seconds

zzz ok

orignal but I can do it more consistently

orignal tell me the number

zzz here's what I have right now, may change it later:

zzz wait for 2 minutes after sending or receiving termination

zzz reduce it to 15 seconds after receiving termination reason 1

zzz retransmit termination (reason != 1) at 7/21/49/105 seconds

orignal why shoud I wait 15 sec in this case?

zzz in case of out-of-order packets

zzz maybe 15 is too long, don't know

zzz maybe not necessary

orignal anyway will change it to consistent time

orignal rather than random

zzz and finally, I wait 250 ms before sending termination again after receiving i2np, relay, etc. (delayed ack) to limit sending

orignal hmm

zzz quic says it's important not to send too much when in "closing phase"

zzz also not sure whether to respond to different ip/port or not while in closing phase. quic says you can if you want...

orignal good point