On Wed, May 24, 2006 at 08:30:10PM -0700, Ian Clarke wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > I can see how this distributes bandwidth among relatively equal > peers, but I'm not seeing a "tit for tat" component here that would > reward peers for storing and transferring data - which was the goal > of my suggestion at the start of this thread. Please correct me if I > have overlooked something.
If nodes don't forward requests, then they get backed off, at present. So they have no anonymity; serving requests is good, because it's the foundation of your security. However, if that's not enough, we can look into making nodes not respond to requests from other nodes which are useless. But lets get the basics right first. Incentives can wait; basic load limiting is the first priority. > > Ian. > > On 22 May 2006, at 11:39, Michael Rogers wrote: > > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > >Ian Clarke wrote: > >>What system? Is it described in a wiki page? I have seen a *lot* of > >>ideas thrown around, but I haven't seen a single proposal. Perhaps I > >>have overlooked it. > > > >I think the rough consensus was: > > > >* AIMD congestion control on each outgoing link > >* A token bucket for flow control on each incoming link > >* Fill the buckets at equal rates to ensure fairness > >* When a peer's bucket is empty, reject its requests > >* When a peer's bucket is full (ie when an incoming link is > >underused), > > add its tokens to another bucket instead > > * My initial suggestion: add them to the emptiest bucket (if > > there's excess bandwidth, give it to whoever asks for it) > > * Matthew's suggestion: add them to the fullest bucket (giving > > peers an incentive to ask for as little bandwidth as possible) > > * We probably need simulations to discover the knock-on effects > > of both suggestions > >* When forwarding a RejectedOverload, possibly reduce the rate at > >which > > the rejected peer's bucket is filled > > * This provides a stronger incentive to conserve bandwidth, but > > could adversely affect paths that share one or more links with > > the path of the rejected request > > * Again, simulations are needed > > > >I could be forgetting something though... > > > >Cheers, > >Michael > > > >-----BEGIN PGP SIGNATURE----- > >Version: GnuPG v1.4.3 (GNU/Linux) > > > >iD8DBQFEcgVRyua14OQlJ3sRAvFgAJ9GBNwsfAGL97R6YxN2cdrHhbNZYQCgo3dg > >1Ir8WIW+DGLEhZMtzV+d1Ko= > >=LRXe > >-----END PGP SIGNATURE----- > >_______________________________________________ > >Tech mailing list > >Tech at freenetproject.org > >http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.2.2 (Darwin) > > iD8DBQFEdSTFQtgxRWSmsqwRAgWiAJ9/L62iMsY+mauV+AOq6DgD/ewrvQCfcKve > VCZjHjG+jbAzfh+prT4WBRk= > =8JZ6 > -----END PGP SIGNATURE----- > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > -- 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/tech/attachments/20060525/4a6bd2c9/attachment.pgp>
