On 05/11/15 22:33, Matthew Toseland wrote: > On 05/11/15 22:21, Bob Ham wrote: >> On Thu, 2015-11-05 at 21:19 +0000, Matthew Toseland wrote: >>> On 04/11/15 22:57, Bob Ham wrote: >>>> That's all helpful, thanks. However, I'm still not entirely sure which >>>> are the "fundamental" problems Toad spoke of >>> - Load management: Performance. Major mechanism design (incentives) >>> problems: The Patch is actively used in practice. Will look into this >>> this year. >> I don't really understand any of this :-) Is this load management >> within Fred (i.e. an implementation issue), or is this some part of the >> protocol? > It's both, just like it is in TCP. Currently load is managed primarily > by the originator adjusting their send rate. This only works if everyone > cooperates. The Patch effectively turns this off, stealing bandwidth. > Ideally we would have a system that doesn't rely so heavily on voluntary > cooperation. TCP is similar to our current approach and works because > most people don't cheat. There is a whole field of Computer Science / > micro-economics called Mechanism Design that deals with this sort of thing. An important bit of context here: When load management fails, other mechanisms kick in, notably backoff. So everyone gets worse routing. I believe that The Patch dramatically reduces performance for non-Patch-using users, boosting performance for the 10% or so who do use it. However this is based on anecdotal reports. I will simulate it soon however.
Unfortunately, incentives-compatible mechanisms are hard. A lot of things work in the real world because the number of people trying to exploit them is relatively small! The broader view on load management again interacts with routing. The current system may work acceptably well, but it is possible - not certain - that it still substantially reduces performance, both in the sense of number of requests, but also in the more important sense of routing not working well, which affects data persistence. I hope to test some new mechanisms in simulation within months, but we'll see how far I get. This is not an "implementation issue", because when a significant fraction of the network gets it wrong, it messes up the whole network. Analogously, new TCP variants are deployed sometimes, e.g. TCP Vegas rate-based congestion control, but they must play nice with existing versions of TCP.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
