-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Matthew Toseland wrote:
> Yep. One request send rate for all neighbours combined.
...
> If it's local, it backs off. Either way it reduces its overall send
> rate via AIMD.

This seems like it might lead to a chain reaction: when a request is
rejected, all nodes along the path reduce their rate for all neighbours,
causing queues to fill up and additional requests to be rejected. For
example:

    E
    |
A---B---C---D
    |
    F

A sends a request along the path ABCD. D rejects the request because
it's overloaded, so B and C reduce their rates. E's request along the
path EBF gets rejected because B has reduced its rate, even though none
of the nodes along EBF is overloaded.

Here's what I'd suggest instead:

* Keep a separate rate for requests to each neighbour
* Decrease the rate when a _local_ RejectedOverload is received
* Send a RejectedOverload if the queue is full

In the example above, only C's rate to D would be reduced initially, but
if A continued to send requests at a high rate then C's queue to D would
fill up and it would send a RejectedOverload to B, which would reduce
its rate to C, and so on until A's traffic was quenched. The traffic
along EBF would be unaffected.

Backoff seems to be redundant under this scheme...

Cheers,
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFEPksWyua14OQlJ3sRAoAHAJ9bzDlDKK0gSCqqY7Fm2yL/LvuiLwCguJWI
UPynXHwZQwWm0zGSYGFvEAw=
=vbbF
-----END PGP SIGNATURE-----

Reply via email to