-----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-----
