Jusa Saari wrote: > Solution: make the send rate a function of the key in question. Requests > to the areas of keyspace that are occupied by slow nodes *should* come at > a slower rate, while requests to the areas with fast nodes *should* go at > full speed.
This sounds promising, but it still depends on senders being well behaved. > It must be a function of the key, not node, since the node we forward to > will forward based on the key, so two requests to the same node will > likely differ in speed based on the key. Any idea how we should divide up the keyspace? IIRC there was a similar issue with next-generation routing - how do we approximate an arbitrary function with a fixed number of points? > So, basically, if we can't forward to the best node, we forward to some > other node ? Which causes the request to go the full HTL, increasing the > total load in the network and making it more likely that any given request > can't be forwarded to the best node, leading to a vicious circle of > raising load. Maybe - or maybe we route around the slow node, adding an extra hop but allowing the network to make better use of the resources offered by fast nodes... > I have said this before and I'm saying it again: routing and load > balancing are mutually exclusive goals. You *can't* have both in the same > network at the same time. Obviously you can't have perfect greedy routing at the same time as perfect load balancing, but maybe a compromise between the two will achieve better performance than either extreme. BTW shall we move this thread to tech to save everyone's bandwidth? A good example of reducing load without reducing coverage. ;-) Cheers, Michael
