#ls2 (irc2p) | #ls2 proposal review channel

zzz there's definitely a benefit to removing ElG from the LSes and going to 4-only, it shrinks the LS by 256 bytes, plus the overhead of trying both on inbound messages

dr|z3d inr.i2p is on that list, orignal. perhaps you can talk to slow?

orignal haven't seen him for a long time

dr|z3d otherwise, I can't see any other site there that's worth pursuing. mostly shit-ware.

zzz dr|z3d, perhaps you can put up a name-and-shame post on zzz.i2p?

orignal we consider inr as dead anyway

zzz might have done it before, can't remember

dr|z3d I believe you did, zzz, I vaguely recall. something along those lines.

dr|z3d look at scanner.linuxfarm.i2p/cgi-bin/defcon.cgi?filter=ElG and I think you'll agree there's nothing there worth making a noise about.

zzz back more to the topic

orignal yes

zzz does making an ElG-only dest LS2 make sense? or not?

orignal 0,4 is slower than 4 only

orignal in my inplemntation

orignal I always use 3 in this case

orignal e.g. LeaseSet2 type 3

orignal I'm even not sure if newer version of i2pd can publish LS1

orignal netplit

zzz kaboom

zzz ok, we do things differently, probably doesn't matter much

zzz let's discuss again in a future meeting, maybe we will think of some good reason

zzz anything else on 3) ?

orignal so I don't publish LS1 and want to stop honouring it for destinations

orignal no

zzz 4) java publishing as ssu2

zzz your item dr|z3d, go ahead

orignal seems we lost him

dr|z3d thanks, zzz. yeah, as convenient as it is to tell an i2pd router from a java one in the netdb, they should both be publishing the same data re ssu2.

zzz sure, part of the plan

orignal same story as with NTCP2

dr|z3d which also brings me to a related issue.

orignal zzz promised to publish SSU2 later

zzz i2p-projekt.i2p/spec/proposals/159 0.9.59 2023-08

orignal everybody knows this "secret" )))

orignal about cost

orignal also i2pd might publish some strange mtu

dr|z3d more reason to standardize on the cost, then. is there any advantage to differentiation, or different values? is there a philosophical difference in what the cost should be?

orignal dr|z3d it's easy

zzz but I know 6 other ways to tell even if you get rid of those two

orignal historically i2pd publoshed NTCP cost less than SSU

orignal me too )))

dr|z3d well now would be a good time to start thinking about eliminating those markers where possible, zzz, no?

zzz it's not worth the effort to hammer out every small detail. we'd all be miserable, or more than we are now

orignal what for?

dr|z3d avoiding segmentation attacks or related issues.

dr|z3d if it's huge effort, fine, nevermind then.

orignal Xeha your turn

zzz I think the segmentation is a lot worse along the other axis, aka router version

orignal also I'm thinking to set cost evern random

Xeha nothing to add from my side now

zzz heterogenous network just a fact of life, even if I can't figure out how to spell it

dr|z3d :)

zzz anything else on 4) ?

dr|z3d 4, no, I'm done.

zzz 5) DDoS / PoW / max leases

zzz let's keep it brief, big topic

zzz interesting discussion over on zzz.i2p

zzz no where close to any good ideas

zzz one simple proposal is increasing max leases, currently 16

zzz 40 bytes each in LS2

dr|z3d yeah, all stems from Tor's DDOS and, somewhat related, dread.onion's ongoing DDOS, to give some context.

orignal wait

orignal about 4

orignal for now consider all SSU as SSU2 if v=2 is presented

orignal e.g. single address

orignal hence not difference for me if it's published as SSU or SSU2

zzz any increase would take two releases, possibly 3-4 releases (one year) for everybody to update, so easy change, but long leadtime

zzz the issue is not spamming the ffs or your connections, because it's O(n**2) as I explain in the thread

zzz right orignal

orignal also another thing

orignal I'm not happy that lease is 40 bytes

orignal no room for options/flags

zzz ok, back to 5)

orignal yes

zzz yeah, I thought of that the other day. No per-lease options

zzz you could do it in the main properties, like key.1=xxx key.2=yyy key.3=zzz

zzz a little messier but not terrible

orignal I can tel you why

orignal when I publish lease I publish only router ident

zzz so LS2 without ElG is 256 bytes smaller, so that's as much as 6 more leases for the same size

orignal but also would be nice to publish transports

orignal to let client choose compatible OB and lease pair

orignal pplease exaplin what are trying ot acheieve?

zzz not sure that makes sense, to copy over RI data into the LS... that's the other router's job

zzz here's the idea:

zzz DDoS attacks all the IBGWs. If you have more leases, you have more IBGWs, harder to DDoS

zzz so, maybe 16 is easy to DDoS and 64 is hard to DDoS? or maybe that's bullshit. discuss :)

orignal not RI

orignal just bitmask of trsnaports

dr|z3d 16 probably takes some effort, 2, not so much. do we need max 64 leases, or would 32 be enough to require a bunch of resources? or is 16 enough to make things non-trivial?

orignal I disagree about "other router's job"

orignal because it leads to deanon

zzz sure, but could also do a property transports=base64(transport bitmask bytes, one per lease)

orignal I publish some fake ident in lease

orignal and force client to lookup

orignal if I also a FF closest to this ident

dr|z3d and re lease count, why settle on static values? scaling count based on usage could also serve to frustrate DDOS attempts while not expending needless resources when no DDOS.

orignal I will identify router

zzz prefer IBGWs already in netdb; don't lookup unknown IBGWs unless you don't know any of them

zzz and actually you don't need to look them up at all. just pick one

dr|z3d I'm also wondering whether huge leasesets could be distributed in sections so not all leases go to a single floodfill. maybe in bundles of 8 or whatever works?

zzz it's one byte lease count so max is 255 leases would be about 10.5 KB

orignal but what I don't have that IBGW in netdb

zzz so that gets split up into 11 or so tunnel messages, good luck

orignal it means I can't pick proper OB

zzz my point is, because of O(n**2) issue, have to make sure your impl doesn't behave like that before increasing limit

zzz don't try to pick "proper OB", just pick at random

zzz not worth the delay to lookup IBGW RI

orignal tell me do we have actual ddos of IBGW

zzz no we do not

orignal or it's theoretical thing?

zzz just theory. Tor's problem today may be our problem tomorrow. Or maybe not.

orignal then wouldn't sucj ddos flood next in tunnel router rather than destination?

zzz the idea is, IBGW enforces some PoW or access rules, doesn't send it down the tunnel unless "verified"

orignal then it comes back to my idea

orignal that we need room for more data in a lease

zzz too much for last agenda item :) please read zzz.i2p thread, comment there if you like, let's discuss again later

orignal like task, etc.

zzz we have workarounds in the properties, if we want

zzz no need for #ls3 just for that

orignal no it's not needed

zzz think about what we need in there per-lease, bring a list to next meeting

zzz foo.1=xxx bar.2=yyy, or bitmask=base64(all leases)

zzz lots of ways to do it if we want

zzz ok, long meeting, shall we call it here?

zzz please participate in IBGW PoW thread on zzz.i2p

orignal fine

dr|z3d just a quick q, zzz. bundling up leases in batches, viable or a non-starter?

zzz not sure what that buys you drz if everybody is going to the same ff

zzz I don't have a histogram of ff target vs. distance-to-key or even any clue

dr|z3d it means if everyone goes to the same ff, then they only get a percentage of the actual leases available, no? so ff's don't get hammered if you're publishing 256 leases, and you can't disocver all leases just hitting 1 ff.

zzz yeah but nobody ever gets any of the the other leases so why did you bother?

zzz I don't know if closest ff gets 100% of the lookups, or 70, or 50, or 20. no idea.

dr|z3d because we're assuming everyone gets the same leases from the same ff. surely that's not likely to happen in practice?

dr|z3d if everyone got the same leases, multi-homing wouldn't work.

zzz but if I send LS a to ff A and LS b to FF b, then A floods a to B and B floods b to A ant it's a pointless mess

zzz but that's temporal randomness, not due to which ff you think is closest

dr|z3d yeah, but if A has, a, then it can just drop b.

dr|z3d "no thanks, I have enough"

orignal hmm, ilita's router has 3000+ transit tunnels now

dr|z3d you'd just check the timestamps.

zzz at this point it's a strange solution to a vague problem, can't nail jello to a tree

zzz don't make me pull out the baffer

dr|z3d well, the entire problem is hypothetical, but if we're discussing increasing the lease limit, it's something to think about. :)

zzz thanks everybody

zzz sure, not like 64 leases nails the jello either

dr|z3d bundles + dynamic scaling, that's my vague proposal, anyways.

dr|z3d 3000 tunnels is a high watermark, orignal?

orignal no

orignal just checking what's worng with Ilita

dr|z3d still seeing the occasional spikes on the network, but they're very short-lived.

orignal see higher memoery usage but it's result of transit tunnels

dr|z3d on the subject of SSU1/2 connection ratios, I'm seeing 4 to 1 roughly on a fast router.

dr|z3d status and limits would be handy things to display on /peers, zzz.

zzz maybe

dr|z3d ideally that page would supplant the individual transport pages for average user, but probably would need some averages there and more stats.

dr|z3d you know, break down of connections by bw tier, ff, country etc. that sort of thing.

zzz none of that really helps the goal of 'help users identify network/censorship problems', but maybe that's not the only goal

dr|z3d I think the censorship goal is probably secondary to summarizing peer connections.. I mean, it's a handy feature, but if you think of that page as a summary instead of a "am I censored" page, maybe you can recalibrate

zzz 'summarizing peer connections' is not a goal, or shouldn't be, nobody cares

dr|z3d it would make those transprot stats a lot more accessible. as they are, you're probably right. too informationally dense for most.

dr|z3d the SSU transport page is especially offensive in that respect :)