On Thu, Apr 13, 2006 at 05:42:23PM +0100, Michael Rogers wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > OK, I think this is the fix: keep a separate rate for each pair of > neighbours, and adjust it in response to both local and non-local > RejectedOverloads. > > E F > | | > A---B---C---D > > D sends a RejectedOverload in response to traffic from A. C reduces its > rate from B to D, and B reduces its rate from A to C. Even if A carries > on sending at the same rate, it is throttled at B. The path EBCF is > unaffected.
Not necessary. Load will be propagated back to A because A is spamming requests and therefore with a good queueing algorithm ultimately gets most of the failures. > > F G > | | > A---B---C---D---E > > E sends a RejectedOverload in response to traffic from A. D reduces its > rate from C to E, C reduces its rate from B to D, and B reduces its rate > from A to C. Initially the path FBCDG is affected, but it starts to > recover as successful requests along FBCDE offset unsuccessful requests > along ABCDE. C's rate from B to D represents a combination of the two > paths. *However* in contrast to the previous approach, B's rate from A > to C remains low even after C's rate from B to D recovers, because B > reduces its rate whenever congestion occurs anywhere on the path ABCDE, > not only when C sends a RejectedOverload after reducing its own rate. > Thus A's traffic remains throttled at B, hopefully allowing FBCDE to > recover... > > Does this sound plausible? Still unnecessary complexity. > > Michael -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20060421/9b369b0a/attachment.pgp>
