For bulk requests: - Queue incoming requests. - Implement strict round robin between peers. - If a request is not accepted in X period, *the request is killed*, not rerouted. - Within a peer's round-robin slot, always accept the request closest to this node's location, regardless of age.
Interesting consequences: - When load is high, we tend to kill requests which are close to the originator. (But without directly using HTL) -- This achieves the effect of slowing down the originator without depending on the originator behaving fairly. -- It also prevents request rates from giving away information about the originator. - Overall more requests will be terminated, wasting a bit more bandwidth. But hopefully mostly early on, so the impact shouldn't be too bad. - Overall much less mis-routing in response to load. - If a request is killed, we'll usually be able to try a different key (for a splitfile), but if we really need it we'll try a different peer (per-node failure tables). - This might make per-node failure tables weaker by killing requests more often; we might need to allow more retries before RecentlyFailed kicks in. However, RecentlyFailed seems to be causing glitches at the moment anyway. - Location is only taken into account within a node's RR slot, so DoS attacks by sending lots of bogus requests near our location are not effective. - Simpler than the current scheme (at least conceptually!). This is loosely based on several proposals made over the years. It's also the result of studying this stuff a little bit and realising that mostly you just need a hack that works for load management, and much of our complexity is probably unnecessary. Thoughts??
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list [email protected] https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
