On Mon, Jun 12, 2006 at 12:32:39PM +0100, Michael Rogers wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Matthew Toseland wrote:
> > It seems like premature
> > optimization to me, lets get the basics right first.
> 
> Fair point - forget about calculating the receiver windows. Let's go
> back to the previous idea of incrementing one of the receiver windows
> (in round-robin or random order) whenever a request is forwarded or
> answered locally, which automatically matches the rate at which we
> accept requests to the rate at which we can process them.

One of the receiver windows? As I recall we were going to use token
buckets for fair sharing (on _incoming_ requests). We can then increment
one of the token buckets every X seconds, X determined by a _global_
AIMD based on successfully forwarded/answered requests... Having one
AIMD per node for _incoming_ requests seems rather strange... By all
means have one for outgoing requests though, based only on that node's
performance.
> 
> If we can't forward a request (because of the bandwidth limiter, the
> congestion window or the receiver window), we return a RejectedOverload
> and don't increment any of the receiver windows.
> 
> There's no special reaction to local RejectedOverloads, because the
> congestion window and receiver window already control the speed of the
> link and ensure fairness. The only node that reacts to a
> RejectedOverload is the sender, which reduces its sending rate if it's
> well-behaved.

Yes. Additionally RejectedOverloads are no longer propagated back to
source. Load propagates back to source not by RejectedOverload's being
forwarded to the original sender (as now), but by nodes punishing
flooders: Allocating quota to the nodes which make fewer requests first,
so that flooders, whether direct or proxy, tend to have their requests
RejectedOverload'ed, with the result that load limits propagate
preferentially back to the original flooder.

At least I think that was the proposal. Whatever we do must propagate
load back to the source. Otherwise all is misrouting and chaos, as in
0.5.
> 
> It's too hot to think straight - does this sound sensible to you?
> 
> Cheers,
> Michael
-- 
Matthew J Toseland - [EMAIL PROTECTED]
Freenet Project Official Codemonkey - http://freenetproject.org/
ICTHUS - Nothing is impossible. Our Boss says so.

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Devl mailing list
[email protected]
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to