On Wed, 2003-11-19 at 17:21, Ian Clarke wrote: > Toad wrote: > > > Is there any reason not to keep the backoff data when a node is dropped > > from the routing table? > > Provided we delete it sometime, probably not. >
It seems to me that there is some reasonable maximum backoff period. For instance, suppose there are N total nodes that ever contact mine during any given hour. And suppose that Q rejected queries per minute has a "small" effect on my performance and on my network bandwidth, and maybe on routing performance. Then, Q/N rejected queries per minute per node has only a small effect, and one node need not reduce its queries per minute below Q/N. Therefore, N/Q minutes per query is the longest reasonable backoff for any given node in the pool of N which contact mine. The number specifies the longest backoff interval nodes contacting mine should use, not the longest interval I will use in contacting other nodes. Perhaps M/Q should be a configurable parameter and part of the node reference data. Or, perhaps the implementation should make it dynamically adjustable by including it in the QR message. The requesting node might also want to calculate a maximum reasonable backoff period for all of the nodes it queries, on the basis of its own output bandwidth and the number of nodes it contacts regularly. This limit would ensure that rejected queries would consume a small amount of the requesting node's output bandwidth. For any given peer, the requesting node will backoff at most enough to ensure that neither its own performance nor its peer's performance nor routing performance in general is affected by rejected query traffic. This number should be kept with the node reference, not in the routing table, so that nodes which leave the routing table and return quickly do not circumvent the backoff. Since backoffs are capped, there is no need for a separate mechanism to remove stale values. -- Ed Huff
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
