On Sun, Jun 18, 2006 at 01:27:12PM +0100, Michael Rogers wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Ed Tomlinson wrote: > > If you are using tokens to control sends then why the high level AIMD? We > > already have a packet level AIMD to control bandwidth so the token system > > should suffice to balance load. > > I agree, packet-level AIMD congestion control and request-level token > buckets are enough. (Actually the token buckets could probably be > implemented at the packet level as well; you'd have to inform your peers > of changes more frequently because of the finer granularity, but the > receiver window / tokens available field can probably be piggybacked on > an existing outgoing packet in most cases.)
I don't understand this. If there is no request level AIMD then there is no reaction to timeouts and preemptive RejectedOverload's! So there is effectively no load limiting! What part of the scheme am I missing? > > > Base assumption is that fair scheduling is what we really want. Is it > > really? > > I'm open to other suggestions (eg the ability to allocate more bandwidth > to your close friends), but fair scheduling is the simplest so I think > it should probably be the default. Once fair scheduling is implemented > we can experiment with other algorithms just by changing the way tokens > are allocated to buckets, which should be a reasonably self-contained > change. Whatever we do, it's NOT GOING IN TO THE CODEBASE unless it propagates load back to its source and thereby effectively limits load, since the existing code already does this. > > > How do we control the number of tokens? I see how we create and use tokens > > but what decides how many we need start with, how do we know if we are > > using too few or too many? > > The size of the buckets determines how large the traffic bursts from > each peer can be - we can experiment with different values in the > simulations. > > > With the above scheme a node is in effect backed off when is > > out going token bucket is empty. > > Agreed, but the backoff periods will be much shorter. > > > Another observation. Quite a few message types ignore the backoff > > conditions > > (eg Swap* messages). We should look closely at these and decide if they > > ready should be bypassing the backoff controls. > > Yup, the bandwidth limiter should take all traffic into account (except > maybe keepalives) and should be changed from a leaky bucket to a token > bucket to reduce latency. The latter I agree with. The former I don't. There was a design decision not to throttle packets other than data packets (which should make up the majority of the packets sent). It was quite simply to minimize per hop latency. Non-data packets may contribute to the bandwidth limit, but they should under no circumstances be delayed by it. > > > The patch I sent to toad_ and mrogers implements the high level (on > > FNPSSKDataRequest, > > FNPCHKDataRequest & FNPInsertRequest messages) (G)AIMD. It sends until a > > window > > is exceeded and then waits for requests to complete before opening the next > > transmit > > window. It also implements part of the metrics mentioned above. > > I thought you were arguing against high-level AIMD above? > > Cheers, > 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/20060620/d1813434/attachment.pgp>
