I'm reminded that in networking at-large, one cannot control the rate at which packets are received (strictly speaking), but only what you do with them, or how you respond.
It seems to me that there ought to be something we can do on our side (like dropping packets, delaying packet acknowledgement, not acknowledging the true number of packets we have received) to directly effect the math on the other end in our favor. Said another way, it would be like sending a 'slow down' signal to our own packet mangler (same node... same machine), instead of sending it off to the remote node as if a desperate plea for them to stop drowning us in packets that we cannot process. -- Robert Hailey On 2014/06/26 (Jun), at 4:19 PM, Matthew Toseland wrote: > Given that a sizeable fraction of the network are messing with load > management anyway by hacking their nodes to largely ignore slow-down > feedback, we should look at some plausible ideas that were posted some > time ago. I have posted branches for these two: > - Allow each peer exactly 1/N'th of our capacity, rather than accepting > all requests up to 50% and only then enforcing fairness. The current > fairness code is an extremely non-linear "cliff edge" and it is likely > that this breaks things. Note also that better fairness should reduce > the opportunity for "cheating" via hacked patches. > - Send "slow down" signal when at 75% load for a peer, not at 100%. > Hence we hope that we will avoid the need for most misrouting/rejects, > while still limiting load. > > Please review the branches I have posted. And test them too! I haven't > tested them as I'm busy with db4o. But they should be substantially > correct. I don't expect that they produce a big performance gain on a > single node, but they do need to be sanity-checked before deployment. > > However, I do think that given that 10% of the network are messing with > their nodes in grossly antisocial ways that really constitute a DoS > attack, we should consider deploying these sorts of reasonably well > thought through but not fully simulated changes. Even if we don't > necessarily have the perfect infrastructure to evaluate their > performance impact, and don't have detailed simulations. > > _______________________________________________ > Devl mailing list > Devl@freenetproject.org > https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl _______________________________________________ Devl mailing list Devl@freenetproject.org https://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
