-----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.) > 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. > 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 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (GNU/Linux) iD8DBQFElUagyua14OQlJ3sRAvNmAJ9Abv0QLj8ieaP/XvSa/QcFFFFowgCgqTJj 16Q04AR1YQoBGGp8yjN6ujI= =FJEG -----END PGP SIGNATURE-----
