On Sun, Nov 16, 2003 at 08:59:50PM -0500, Edward J. Huff wrote: > 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.
Umm, no. It's the other way around. If we get a QR we try another node; if we get a DNF we return DNF to the requestor. > > 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. Yuck. They will reconnect, and they will use a LOT of CPU doing this. Closing connections is not a good idea. Reducing connection limits is not a good idea. We could close the connection and blacklist the identity, for disruptive nodes. > > In addition, the node should consider reducing maxConnections, See above. Less connections = MORE (cpu) load. > and if necessary, the size of the routing table. Perhaps these > could be allowed to increase again later if load stays low. > > -- Ed Huff > -- Matthew J Toseland - [EMAIL PROTECTED] Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so.
signature.asc
Description: Digital signature
_______________________________________________ Devl mailing list [EMAIL PROTECTED] http://dodo.freenetproject.org/cgi-bin/mailman/listinfo/devl
