Many nodes now exceed their output bandwidth regularly and as a result issue many QRs. We are trying to reduce the bandwidth wasted sending QRs, and the waste of resources which occurs when a deeply chained request gets QRed. The node which first receives the QR does not try again with a different node in its routing table, as it would if it got a DNF. Instead, it passes the QR back, and all of the preceding links pass it back to the original requester.
Thus, a QR is a disaster. It would be better if the request had never been sent to the node which is going to QR. The current experiment is exponential backoff. I agree with edt here: ----- <edt> we are now doing backoff - does expontenial make sense? <edt> I suggest that a randomized linear backoff based on the pDNF(node)*random()*constant would work better. <edt> when 'constant' is determined by a feedback loop <edt> designed to minimumize the overall pDNF <zab_> I'm more concerned if the exponent ever gets reset <zab_> I'm seeing backoff values of half an hour <edt> zab_ why does an exponent make sense given the patterns of QR we see? <edt> I do not think exponential backoff makes than much sense... backoff yes. exponential no. ----- I would use pDNF(node)*(random()+0.5)*constant so that the backoff is never really small. But, there is a way for a node to reject requests without QRing them. It can close its connections. A node which has a large backlog of data to send out should close most of its connections (except those which are in use for trailers) until the backlog is reduced. The node can predict precisely how long this will take (at minimum) and can make a tradeoff between the cost of re-opening the connections vs. the cost to the network as a whole of issuing QR's. In addition, the node should consider reducing maxConnections, and if necessary, the size of the routing table. Perhaps these could be allowed to increase again later if load stays low. -- 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
