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.
Ed, I like what you are describing here. And there are many good ideas being presented. You take into consideration more than just the local node. You recognize that different nodes have different bandwidths, by using averages. It even approximates a Rate (oh lord, not that word again) between a pair of peers. I also liked Tom K's LIFO/FIFO presentation with supporting queueing examples. I must admit I did not respond to it because I am somewhat intimidated by the complexity of the idea, *and its global consequences*
One thing that bothers me is that N is *completely* out of our control. Someone with moderate resources could easily abuse this, not necessarily for their own gain, rather to spoil the network.
No one has said that trailers, or queries, are more deserving of a steady transfer rate (QoS). Perhaps we should ask ourselves this question: It seems logical that we would allocate "more" of the bandwidth to trailer(content) transfers than to queries. After all, a single query is much smaller than a single trailer. So in a perfect network, where every query is resolved accurately, and all queries are for valid keys, the ratio of content:query would be quite high. Perhaps 1% of network bytes spent on the queries (average size 100 bytes), and 99% of the bytes spent on moving the content (average size 10000 bytes). In a "perfect" network. I'm throwing numbers around that attempt to reflect reality. Allow for *some* queries that don't resolve, and imperfect routes, and we can afford to give up a few percent more to queries.
Currently the /average/ rate of queries between two nodes is about 3.3 queries per second. I just want to put a reasonable number in peoples' minds. Of course any random pair of nodes will have a different number, but let's frame what is reasonable to expect. I draw this from a global average of 10K qph, divided over the common RT size of 50 nodes. I do not deal with the uncontrolled number of requestors, rather I draw off what other people have reported for lqph. Could usage patterns change radically? Okay! Then let's say 2 to 6 qps is the norm.
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.
Q is likely to be a function of the outbound bandwidth, which the N requestors can't be expected to know ...
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.
so maybe we can -tell- them about Q (our limitation) ...
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.
apparently I agree (above) with your logic perfectly :)
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.
i think this should be "at minimum," but maybe we can compromise by saying on average (for a slightly randomized backoff) ...
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
