Damn, this got too long. If "My Solution" (see below) has been discussed before, please point me to the topic so I can read what was said.


The problem:
------------
First, the number of QR:s should be reduced since they degrade the efficiency of the network. After all, it would be better if *somehow* every query was only routed to a node which had the capacity to accept it. Second, there are other problems related to QR:s, having to do with routing statistics. My solution to the first problem actually takes care of the second as well. Read on...



Hypothetical setup:
-------------------
For simplicity, let's consider a homogeneous network with 100 nodes, where each makes 1000 queries per minute. Also, let's say that each can accept only 10 queries per minute, and does so by accepting 100 queries (all at once) every 10 minutes.



Motivation of my solution:
--------------------------
Ideally, we would want every desired query to be accepted, but that is not possible since the total number of queries made per minute is 100*1000=100000, and the total number of queries accepted per minute is 100*10=1000. So, we simply can't have everything we want. Nodes have to curb their appetites.


Realistically, the best solution will result with each node making 10 queries per minute. But, to solve this, we can't depend on nodes to use self-restraint, unless we can make it in their interest to do so.


My solution:
------------
My solution is analogous to a doctor's office: each node (acting as doctor) keeps a schedule of "appointments" for other nodes (patients), letting them know when they can send queries.


Any queries a node sends outside of a scheduled appointment should be answered with a highly reduced priority (many will QR here). Also, any such queries should contribute to the doctor "getting mad" and tightening up when the patient tries to schedule another appointment. The doc has to penalize the patient enough to make the patient's best strategy to stick to the appointments. To a lesser degree, the doctor should also penalize the patient if he fails to show up for an appointment. The patient then has an incentive to keep appointments and to not show up unannounced.

The result would be a much greater proportion of QA:s and a decrease in the number of queries made. Going back to the hypothetical, a requesting node would want to make 1000 queries in a minute, but might only find, say, two nodes in that minute willing to accept up to 5 queries each from him. The requesting node would then route 10 queries to those nodes, and drop the 990 others (doing so *as if* all nodes in the RT had sent QR).

Note that we don't have to worry about what will motivate the doctor to keep appointments, since today there's always the possibility of a node choosing to be transient. Also, NGR will prevent the quacks from being routed to.


Details still to be worked out:
-------------------------------
What strategy should the doctors and patients use for scheduling appointments? I leave this question unanswered for now. If the basic idea has any merit, we should be able to come up with some workable strategy.



Other problems my solution solves:
----------------------------------
The above solution also ameliorates the problem of unsteady QR:s making routing times highly unpredictable. Given the patient has an appointment with a doctor who usually keeps appointments, the patient will have a better estimate of pSuccess than today.



Why some other solutions don't work:
------------------------------------
Both probabilistic queryreject, which seeks to smooth out the unsteady pattern of queryrejects, and Ed's idea (trying to better predict that pattern) suffer from the same problem: they still result in a less-than-ideal system where there are far more queries made than accepted.


Also, without some sort of system for limiting the number of queries from a single node, won't a node be encouraged to make a ton of queries in order to crowd out other nodes' requests?

Humble, closing inquiry:
------------------------
Thoughts?

-Martin


_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl

Reply via email to