On Thu, Apr 13, 2006 at 04:06:02PM +0100, Michael Rogers wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hmm, my suggestion needs to be modified to deal with the following scenario: > > E F > | | > A---B---C---D > > D sends a RejectedOverload to C, which reduces its rate to D. If A > carries on sending at a high rate then C sends a RejectedOverload to B, > which reduces its rate to C. This affects the path EBCF even though > there are no overloaded nodes along that path. > > Solution: keep a separate rate for each pair of neighbours (previous hop > and next hop).
That seems a bit much. Can it be avoided? I worry that we won't get enough data if we have to keep one for each pair. How much of a problem is the above? > > D sends a RejectedOverload to C, which reduces its rate from B to D. C's > rate from B to F is unaffected. If A carries on sending at a high rate > then C sends a RejectedOverload to B, which reduces its rate from A to > C. B's rate from E to C is unaffected. Result: A's traffic is quenched > without affecting the path EBCF. > > The disadvantage of this approach is the need to keep state for each > pair of neighbours - but the amount of state needed for an AIMD token > bucket is very small (two integers), so it should be practical for up to > a couple of hundred neighbours. If there is enough data. > > Unfortunately it still doesn't deal with scenarios like the following: > > F G > | | > A---B---C---D---E What's the problem here? My basic concern is whether it will get into freeze-down troubles with loops (any real network will have many many loops). > > Cheers, > Michael -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list Devl@freenetproject.org http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
