#ls2 (irc2p) | #ls2 proposal review channel

eyedeekay I looked pretty closely at it because I think this proposal is a good idea if it can be made workable and safe, I came with about half a page of notes on it which I think might fall under the heading of "implementation" stuff: paste.idk.i2p/AdvancedAlpaca/read

orignal so, I was aginst it because I need to have a way to know if a tunnel participant is able to handle heavy traffic

dr|z3d one thing that occurred to me re requesting and obliging with b/w limits, is.. how, if possible, are we going to enforce b/w requirements over the entire tunnel chain?

orignal in case if I really need one

zzz orignal, so does this resolve your concerns with tunnel throttling, or not?

orignal yes

orignal as long as I know my limits or can request my limits

orignal otherwise I pick X routers and never know if they can make it

zzz I think we need a third request parameter, maybe 'l' for limit, to ask the IBGW to drop over the bw limit, which would help if you're getting ddosed

zzz m < r < l

orignal yes makes sence

dr|z3d and all routers in the tunnel should respect the requirements of the router initiating the tunnel?

orignal about reservation yesterday

zzz let's take dr|z3d question first, then eyedeekay's list, then we'll talk about onon's issues from yesterday

orignal if some bw is reserved, tunnel originaotr must produce such activity say in first minute

orignal if not then no more reservation

zzz dr|z3d, please elaborate your question?

dr|z3d ok, I'm asking how I can ensure my b/w requirements are met end-to-end.

orignal every patritipant sets ret code

orignal if can't make sets 30

zzz well, all you can do is ask the participants, there's no guarantees, but yes, as orignal says they return a commitment in the reply, or a rejection

orignal ofc you set it in each record

dr|z3d ok, so my requirements are being passed on from router to router until the endpoint?

orignal no, the originator should specify it for each record

zzz dr|z3d, each build record is only visible to one router

zzz there's a build record for each hop, and a reply record from each hop

dr|z3d ok, I understand that, so the next router adopts the requirements I've set and passes those on to the next router?

zzz no, one hop does not talk to the next, other than to pass the encrypted thing to the next guy

orignal no it doesn't pass anything

orignal you set it when create TBM

zzz the originator gets all the reply records back and looks at them all to see what they said

zzz make sense dr|z3d ?

dr|z3d kind of, except I'm still not clear on how we ensure after the gateway the requirements are still being met?

zzz you get back the 'promise' or rejection from each hop.

dr|z3d I mean, I can control the tunnels at my end, but not the tunnels built by the endpoint router.

orignal every hop must repond with 0 ret code

zzz but you don't "know" if he actually does it, other than by watching the traffic for 10 minutes

orignal no you can't

orignal it's thier reponsibility

eyedeekay On the other side the bandwidth requirements are the other guy's responsibility right?

dr|z3d that's the thing I'm not clear on..

eyedeekay Oh wait wrong thing

orignal if stormy runs na outproxy he must reserve a lot

eyedeekay But yeah doesn't seem like you can stop people from lying, but that's already true

zzz it's a "weak" promise of bandwidth allocation, they could lie, or conditions could change, but "normally" the promise should be good

orignal if I'm a client go to youtube through http proxy I must reserve a lot of bandiwdth too

dr|z3d If I have a b/w requirement, I can request that for tunnels I build, not for the target tunnels. So what's to stop the traffic tanking at the gateway?

zzz oh, you're talking about the other guy's tunnels

dr|z3d Right.

orignal if you run an IRC server and some idiot send a lot of data it makes sense to drop at IBGW

zzz nothing. if you're talking to multiple peers, like for bittorrent, it's not an issue. If you have one connection to one other guy, yeah, all bets are off

orignal you always know what is the service of other guy

orignal and you alsways know what you are going to do

dr|z3d ok, so conversely, are we proposing that the service operator can set b/w requirements for accessing his service and allocate minimums on that basis?

zzz is your question answered now dr|z3d?

dr|z3d I think so, more or less, zzz. Not doubt my grasp of things will get better over time, ideally as this conversation progresses :)

zzz no, this proposal does not address that at all. this is only about your tunnels, not about the other guy's or any negotiations

dr|z3d *No

dr|z3d ok

zzz let's move on and we can circle back later if you need more

dr|z3d sure, please do. don't let me hold things up.

zzz next was eyedeekay list which I haven't looked at and probably won't until after the meeting

zzz eyedeekay, can you summarize the non-implementation issues or thoughts for us here?

eyedeekay Yeah I'll try to summarize, just a moment while I type

eyedeekay I think over-allocation DOS is actually a pretty observable event and in the right circumstances we can react to it using mostly information we already keep track of

eyedeekay Based on the premise that an over-allocation DOS of this type is only at an advantage to a resource-exhaustion DOS because it doesn't have to send traffic

eyedeekay So, the answer is if they ask for it, make them send traffic, a

eyedeekay a'la orignal's earlier suggestion of "if they don't transmit something over the reserved tunnel in the first minute, drop it"

zzz ok so this is about onon's comments from yesterday in saltr

orignal yes

zzz which I promised to bring up here, let me attempt to summarize

eyedeekay Yeah I also have a section on fingerprinting

dr|z3d I think that's what orignal was suggesting. use your allocation, or lose it.

eyedeekay orignal's suggestion TBH might be better than the strategy I propose in my notes

zzz he said it's not workable without overallocation, but then you're maybe not delivering what you promise, so the whole thing is useless

zzz and he's concerned about allocation DOS

zzz does that about summarize his concerns?

eyedeekay I think so

orignal his point it

orignal *is

zzz orignal, what are your thoughts about it?

dr|z3d I think in addition to determining whether a request is valid in the first minute, we should also detect if the request is using the requested b/w, and if not, scale back whatever we're resevring for their use.

orignal the an advesray can request all bandwidth of a router

orignal and force it to not accept tunnels

orignal that's why we shouldn't reserve bandwidth for 10 minutes

orignal but only for a minute or so

dr|z3d right, that's what I'm getting at.

orignal later use actuall bandwidth usage

orignal why minute?

zzz I'm not sure 'use it or lose it' will work

dr|z3d we keep an eye on usage, and if it doesn't meet the requirements set, we drop the allocation and the router goes to the bottom of the priority list.

orignal because a tunnel can be build a a replacement

orignal zzz, my point it

orignal I(client) watch video from youtube

orignal then when a tunnel if about to expire I build a new tunnel and request bandwidth from previous

orignal expecting to switch to new one shortly

orignal however if I'm tired to wtach youtube that reserved bandwidth got released after a minute

orignal and ofc we should set some min bandiwdth suitable for most tunnels

eyedeekay In the my notes I suggested we tie the "use it or lose it" principle on the client side to "reduceOnIdle" i.e. "reduceOnIdle" threshold hits, `m` gets turned off until activity happens again

zzz it seems like you have to track both reserved and actual bandwidth

dr|z3d yup

zzz and it seems like overallocation is mandatory to prevent DOS

zzz if you're a server, you don't control which tunnel the client side selects

dr|z3d we probably want to track usage per requesting router and total usage on the given tunnel, and adjust allocation accordingly.

dr|z3d tunnel/set of hosted tunnels.

zzz so 'use it or lose it' is hard because you don't always know which inbound tunnel will get the traffic

orignal_ what was the last sentence?

zzz even for outbound, you can control which tunnel it goes out on, but you don't know how fast the far-end client will actually take it

eyedeekay re: reduceOnIdle that was an "implementation detail" about the default behavior of clients, so the client is able to to decide when to ask for it based on what they're doing so that there are less unnecessary values in TBM's

zzz i'd rather not get too deep into the implementation of how to pick your m and r values here

zzz back to onon's concerns, do we think that _some_ implementation is possible that cannot be DOSed, or is he right that this is hopeless?

orignal I disagree with him

eyedeekay I think it can be done as well

orignal and bandwidth reservation is implemntation details

zzz I do too, maybe he'll be right in the end, but we need a protocol before we can try it, and I think it's worth trying

zzz I think any implementation will evolve as we learn, and as the attacks evolve

zzz can we move to the fingerprinting/correlation issue? eyedeekay you have thoughts?

dr|z3d definitely worth trying, but in order to enable easy rollback if it causes more issues than it fixes, we probably want to keep the code compartmentalized.

dr|z3d and of course an on/off toggle would be good, for easy opt out.

eyedeekay Pretty simple, only allow coarse values for the requests, a "high, medium, low" if you will, corresponding to values we decide on, and reject custom values by treating them as if they weren't there

zzz agreed dr|z3d

eyedeekay Coarse means most people will choose the default, and the set will only break into 3 pools

eyedeekay OR the configuration that faces users is a boolean, and the client picks for you based on your usage, which is more complicated

eyedeekay This also serves the purpose of preventing accidental misuse, we don't want people ignorantly asking for 9999 whatever they think they're asking for

eyedeekay EOT

zzz well, I think the router would set the values, or round or randomize the values requested from the client side, not just pass them through as-is

zzz or it would use actual values from recent tunnel average, not what the client asked for at all

zzz maybe after implementation, java and i2pd would agree, 'e;t

eyedeekay That's certainly better than letting people set dumb values, and rounding is at least introducing some coarseness

zzz 'let's round to nearest 10 KBps, or 25KBps' or whatever. but I think it's too early to make those choices now

dr|z3d the less the user has to do, the better.

eyedeekay Yeah I don't know for sure what the values should be yet, but I do think we should decide which ones are valid

dr|z3d less things to break :)

eyedeekay Also that^. The knobs, wherever they exist, should be safe

zzz but I don't think the value goes straight from some UI to the TBM message unfiltered

dr|z3d if the user has to tweak requirement params per tunnel/session, this will get tedious fast.

zzz I'm not sure there needs to be any user-visible knobs at all

dr|z3d agreed, zzz.

dr|z3d if we can automate the requirements based on local stats, all the better.

zzz other than say in i2psnark where there's already bw knobs

eyedeekay That's interesting, I approached this with the assumption that there might need to be something in I2PTunnel or I2CP or SAM to turn it on

dr|z3d snark's not important. there's no expectation of realtime.

zzz but even if the max is set for 9999 you don't pass that in as the 'r' or 'm' value, you'd use recent history

zzz even for snark you could set a 'r' value for requested, without setting a 'm' value for minimum

orignal ofc it must be an I2CP param

zzz as that helps the hops allocate their bandwidth

zzz not sure about 'ofc', you could do it based on tunnel type and recent history

zzz I'm more 'maybe'

zzz agreed with dr|z3d that if it just happens automatically that's better

orignal later on yes but you don't know how much you need initially

zzz well, you could just not set 'm' or 'r' for the first set of tunnels, only set it 10 minutes later when you have some data

eyedeekay I get it, I think, zzz's suggesting you dial it in based on the activity you see

orignal agree

dr|z3d yup, reactive requirements.

dr|z3d I think we're all agreed that's the only way to do it right.

zzz I don't think we need to set these in every request, maybe you know enough to set them, maybe not

dr|z3d Letting the user set arbitrary requirements is a recipe for abuse.

eyedeekay Yeah that definitely sounds better

zzz ok super sounds like we're agreeing on the big stuff. details are details...

zzz any other big topics or issues?

dr|z3d I'm also with orignal thinking that we don't allocate b/w for 10m slots. We do it based on the last minute or so's usage.

dr|z3d you want to give us a short update on where you are with LS spam, zzz?

zzz yeah I haven't thought a lot about time 'slots' for estimation/allocation, I'm open to ideas

orignal no

zzz I'd rather not change subjects here dr|z3d we can do that later

dr|z3d fair enough, zzz, I thought you were asking about general stuff and wrapping the conversation up. my bad. :)

zzz so if there's not much else on this proposal, let's try to make a decision on 'ok with minor revisions' or 'need another review after updates'

zzz no prop drz, we're all a little rusty on meetings

zzz or maybe 'I want to see the updates and then decide if we need another review'

dr|z3d decision-wise, I think we've got enough to put something together as a starting point.

dr|z3d orignal, eyedeekay?

eyedeekay If we're voting, I think 'OK with minor revisions'

zzz the goal when done is I copy the guts of the proposal into the tunnel spec

dr|z3d really it's only going to start making sense (or not) when we've got something to test on the network.

eyedeekay Mostly clarifying revisions

orignal ?

zzz the big change is adding 'l' for limit, probably for IBGW only

orignal makes sense

zzz the implementation notes section I will update, but may not get copied to the spec

zzz not sure how much of it goes into the spec

zzz so it's 'ok with minor revisions

zzz I'll let you all know when I've updated it, ETA about a week

eyedeekay Thanks zzz

zzz anything else for the review?

zzz thanks everybody

dr|z3d thanks

zzz dr|z3d, re: LS spam, I promised eyedeekay an MR this week, but got sidetracked by RAP/RAR issues, and don't have much time next few days

zzz so more likely this weekend or early next week

zzz congrats to us all for remembering how to do meetings!

dr|z3d np, zzz, no rush. I just figured orignal might find it instructive if you were in the throes of something :)

orignal what?

zzz yeah I'm not prepared to do any instruction, and not sure this is an area where we need to do the same thing anyway

dr|z3d ok

zzz orignal, LS spam mitigation

orignal ok

orignal where? on FF or in dest?

zzz I'm not prepared to discuss it now, gotta run, ask me in a week

orignal fine

hk thanks, happy to witness this

zzz not sure it's a shining example of Open Source Decision Making but we do the best we can...

zzz but it's one more protocol change so get to work on go-i2p, you just fell further behind ))

hk zzz: im on it :)