-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Matthew Toseland wrote:
> - If we simply move on to the next node (since backed off nodes are
> ignored for routing at present and that seems to work), then to some
> degree the load will go to where it is least overloaded...
...but at the cost of extra hops. This is a hard one. Longer paths waste
bandwidth, but so do rejected requests. If the sender retries when a
request is rejected and the request follows the same path, it will just
keep getting rejected.
> a very slow node at a good point in the
> keyspace will then inflict great harm.
Agreed, I think at some point we have to try to route around slow nodes.
I suppose the question is where on the path the re-routing should occur
- - near the source or near the bottleneck?
> What do you mean by sliding window flow control? Doesn't AIMD suffice?
In TCP the sending rate is limited by the minimum of the congestion
window and the receiver window. The congestion window represents the
capacity of the link, and grows and shrinks in response to packet loss.
The receiver window represents the capacity of the receiver - the front
of the window is moved forward when the receiving process removes data
from the buffer, and the back of the window is moved forward when
incoming data is added to the buffer. The receiver specifies the window
size in acks and keepalives ("ack, send 3 more... ack, send 2 more"). If
the receiving process stalls then the back of the window catches up with
the front and the sender can't send any more data, no matter how large
the congestion window.
So instead of pinging your neighbours to see how overloaded they are,
the receiver window should tell you when they're ready to receive more data.
> Maybe... IMHO if we can implement a form of load balancing that doesn't
> have the problems associated with the current one then it would be
> worthwhile for me to do it immediately; we just have to thrash out the
> design... that is assuming the design is 100% bulletproof...
Cool, it would definitely be better if you implemented it. I'm writing a
simulator at the moment for some other work so hopefully I'll be able to
do some simulations if you need any.
Cheers,
Michael
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFESWDiyua14OQlJ3sRApxdAJ41mJa/pi8HYOdYNwgi0GPdYvPaKgCcD6R6
wnNoXCcdJPUY8p68DxhJB4A=
=0BwN
-----END PGP SIGNATURE-----
_______________________________________________
Devl mailing list
Devl@freenetproject.org
http://emu.freenetproject.org/cgi-bin/mailman/listinfo/devl
