On Tuesday 13 January 2009 14:21, Matthew Toseland wrote: > The current backoff changes seem to be making the problem worse and causing > most of the network to be backed off, but it could just be related to > different load at different times of day, so we'll give it a while longer. > > A proposal to solve the problem: > - Do NOT backoff on getting a quick transfer failure (a transfer > cancellation). Hence transfer backoff only occurs on the original node. > Transfer cancellations are treated as DNFs - they might be malicious, so > route the key elsewhere next time. > - If a transfer takes more than 15 seconds, send a transfer failure downstream > to free up the original request, do transfer backoff on the node, and switch > the incoming transfer into "turtle mode". Hence real time requests are fast. > - If a turtle mode transfer receives a cancellation, kill it, end of story. > (All of the nodes along the chain, except the first one, will do this). > - If a turtle mode transfer completes, store it to our datastore and offer it > via ULPRs to those who have requested it. Hence if the only node with the > data is slow, we still get the data, but slowly, for queued downloads / > subscriptions. > A related matter is how to deal with inserts. A good DDoS at the moment is to set up a fast node, and have it do really slow inserts. It will stay on the network even on opennet because it serves requests quickly. We can't backoff on slow inserts because they propagate over the network - that would make it trivial to cause universal backoff. And the slow inserts will cause nodes to accept few requests due to output bandwidth liability limiting.
What is the solution to this one? Don't take slow inserts into account when estimating output bandwidth liability? Require inserts to have a reasonably fast transfer?
pgp0ENFuWh5eF.pgp
Description: PGP signature
_______________________________________________ Devl mailing list [email protected] http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
