Matthew Toseland wrote: > The reason for the current lack of performance is overcompensation for > load, as evidenced by the low bandwidth usage.
I think you're probably right - we're responding to load by shutting down links, which makes the remaining links more likely to become overloaded... > We could take out load balancing completely, but that might > result in a significant slowdown due to slow nodes. There's a fundamental tradeoff here: either we redirect traffic from slow nodes to fast nodes, ie misrouting, or we allow the slow nodes to determine the performance of the network. Both approaches create attack opportunities, and I think Ian's right that we need to reason this through from first principles - unfortunately we don't just need a mechanism that works, we need a mechanism that's robust. > Load limiting: Sender side, determining how fast to send requests into > the network. If there are too many RejectedOverload's, the sender slows > down. This will ensure the network is not overloaded, full stop. It > works for TCP/IP, it should work for us. It works for TCP as long as all the senders are well behaved. We can't depend on that assumption. > Load limiting without load balancing: If there are slow nodes near the > sender, and we send these an equal proportion of our incoming requests > (according to their location), then most of those requests will be > rejected, and this results in an overall slowdown. Again, assuming the sender is well behaved. If not, the sender's traffic overloads the slow nodes and they reject all traffic from other nodes, causing everyone else to slow down. This doesn't even require the sender to be malicious, just selfish. The sender might also reject incoming requests to slow everyone else down, leaving more bandwidth for himself. > I don't think > ethernet collision detection is a viable model for backoff. I agree with this - backing off reduces the load on one peer but increases the load on the others, so it's a more complex picture that ethernet backoff. Cheers, Michael
