eyedeekay
I'm not sure I see the point, is there a problem with reseeding that quic enables us to solve?
eyedeekay
I can't think of any, but I'm open to ideas
eyedeekay
In terms of reseed-tools it's about a 12-20LOC change to support, maybe less, I already know where it goes if we want it
dr|z3d
more problems than solutions.
dr|z3d
the main one being lack of quic support in java i2p.
orignal
the proint is that in some bantustans quic might work but regular tls not
dr|z3d
if the hosts are blocked, protocol is irrelavant.
zzz
new tunnel bandwidth proposal: i2p-projekt.i2p/spec/proposals/168
dr|z3d
looks good, zzz
dr|z3d
how will tunnels calculate min and requested b/w?
dr|z3d
from the requesting client I mean..
dr|z3d
e.g. I'm browsing a video site on the network, how will my client tunnel set the requirements?
zzz
up to the implementation ))
dr|z3d
that sounds complicated
zzz
not necessarily
dr|z3d
presumably the simplest way to set requirements is at the tunnel level, globally per tunnel, though that's a fairly inefficient way to determine what's actually needed.
zzz
just take the avg or max of current tunnels in the pool, done and done
zzz
but you can make it as complicated as you want, up to the implementation
dr|z3d
ok, will be interesting to see how that works in practice.
dr|z3d
is there scope for requesting / indicating latency?
dr|z3d
I might not care so much about available bandwidth, but I might care more about latency.. maybe there are routers out there with less capacity, but lower latency, so having latency in the mix might spread the traffic better?
zzz
there's scope for anything, but latency usually is what it is, unless you're going to assign a higher priority to certain tunnels
dr|z3d
ok, just a thought.
zzz
there should be room in the build request to send some bitcoin to the hop for better service, if you'd like to write that up ))
dr|z3d
haha
dr|z3d
behave :P
zzz
not a new idea, that's what meeh wanted to do with anoncoin, and that's one reason we have a big space for arbitrary options in the new build messages
dr|z3d
a boolean value passed to the router might be a useful compromise, with, as you say, some routing priority. either a tunnel wants low-latency, or it doesn't.
dr|z3d
add a limiter on both ends so the requesting router can only make x requests / period, and the receiving router will only accept x requests / period for low latency tunnels, and it might be viable.
orignal
I still don't understand why do we need to limit tunnel bandwidth
zzz
bandwidth has always been limited. you just don't know what the limit is.
orignal
I mean per tunnel
zzz
the proposal does not specify or require any particular limiting at all
zzz
yesterday you requested "notification", this is my response
orignal
let me check
dr|z3d
what about a low-latency option in build and reply, orignal? what do you think?
dr|z3d
I'm thinking you can have either request bandwidth or low-latency, not both.
dr|z3d
and maybe a global low-latency tunnel cap on the router.
zzz
updated proposal based on comments, mostly in 'implementation notes' section
dr|z3d
> conbination
dr|z3d
(Security Analysis section)
zzz
thx
dr|z3d
np
zzz
didn't know Kurt Opsahl went from EFF to Filecoin. Marcia Hoffman is on their board also
zzz
guess we don't need to suck up to him at conferences any more ))
zzz
holy shit Filecoin has a $58 million dollar budget. No wonder everybody is going there.
zzz
they must hand out grants like candy. They gave Freenet $75K for a rust version
dr|z3d
freenet!
dr|z3d
surprised that still exists.