~dr|z3d
@RN
@RN_
@StormyCloud
@T3s|4_
@eyedeekay
@orignal
@postman
@zzz
%Liorar
+FreefallHeavens
+Xeha
+bak83_
+cumlord
+hk
+profetikla
+uop23ip
Arch
DeltaOreo
FreeRider
Irc2PGuest19353
Irc2PGuest22478
Irc2PGuest48042
Irc2PGuest64530
Meow
Nausicaa
Onn4l7h
Onn4|7h
Over1
acetone_
anon4
anu3
boonst
juoQuua9
mareki2pb
not_bob_afk
plap
poriori_
shiver_1
simprelay
solidx66
thetia
tr
u5657
weko_
eyedeekay
Nobody has any requests of you orignal, AFAIK, we're discussing the prospect of limiting the total bandwidth that any given participating tunnel is allowed to use proportional to the available bandwidth
eyedeekay
i2pd has some very different opinions about whether or not to do this I gather
orignal
as I mentioned before I'm fine with it
orignal
but this number must be reported
orignal
we do nothing if we receive TBR and have enough bandwidth and number of tunnels we accept
eyedeekay
The idea here would be to prevent a small number of tunnels(less than the configured maximum participating tunnels) from using up all the available bandwidth, so I don't see these ideas in conflict
orignal
and what's your idea?
orignal
if I got a fat tunnel
eyedeekay
Essentially same as before, except for the changes here: git.idk.i2p/i2p-hackers/i2p.i2p/-/merge_requests/200
orignal
so what is the change about?
eyedeekay
It limits the bandwidth available to a participating tunnel to a proportion of the total available bandwidth
orignal
what if one exceeds?
eyedeekay
Then it starts to drop messages
orignal
worst idea
orignal
if you do it this limit must be in your RI
orignal
otherwise how I know if I can use your router for video streams
orignal
e.g. you must tell the network what's your limit per tunnel
eyedeekay
Well the proportion is determined by whether it is L, O/P, X, or M/N so you can know what the likely behavior/available resources are
zzz
we could put the limit in the build response msg
eyedeekay
Interesting idea
orignal
zzz yes
orignal
because I need to understand if I can use a tunnel for heavy traffic or not
orignal
and be sure it will not start malfunctioning
orignal
hence jujst start dropping is a bad idea
orignal
so what's the propoprtion now?
zzz
and/or requested bw in the build req msg
zzz
that was one main idea why we put a mapping field in each
eyedeekay
orignal in the MR the limits are as follows: total limit / 2 for L routers
eyedeekay
total limit / 4 for O/P/X routers
eyedeekay
directly between those two points for M/N routers
orignal
is it constant or can be changed?
eyedeekay
It's not even merged yet, can be changed
orignal
not is it contsnat or dynamic?
eyedeekay
Constant in that sense
dr|z3d
it's currently fixed at the time of the request.
dr|z3d
for the duration of the tunnel.
zzz
proportion is documented in the MR linked above. Not necessarily what we'd actually do, just a placeholder
eyedeekay
zzz it seems like an excellent idea to me offhand, the proactive ask-first version in particular strikes me but I guess if you ask a big number then everybody says no it's not so good
eyedeekay
So is it better to know when you run out or know you're not likely to to or both?
zzz
but that placeholder is not based on current available bandwidth, which perhaps it should be
zzz
the goal is to do the RED on the tunnel that's the hog, before you get to the RED on the full part. traffic flow
orignal
also keep in mind that an advesary can reserve all availble bandwidth and make a router unusuable
eyedeekay
Yeah but this should hypothetically make such an adversary have to work harder
dr|z3d
that's where throttling tunnel requests per peer kicks in orignal.
dr|z3d
there's an argument to be made for the tunnel throttler to work in tandem with the peer throttler so a given peer is throttled before they've requested all aavailable bandwidth.
zzz
ok, based on this discussion, the MR is not yet ready for merging, and some of the ideas above, if adopted, would require a separate proposal
dr|z3d
worthwhile discussion.