I would appreciate somebody checking my logic here...
The problem with the shared-window solution is that a failed CHK insert has the same impact as a failed SSK request. However the former will often have caused many nodes to be backed off, whereas the latter will usually have caused only one node to be backed off. The basic currency here is backed off nodes: The load limiting algorithm's purpose is to adjust the rate at which requests are sent in order to stabilize the amount of backoff happening. Separate windows for each type of request may be sensible, but ONLY if they also have separate backoff for each type of request. If we have a unified window, then we need to have proportional impact of different failure types. What we could do is report each RejectedOverload separately, even if a request generates several of them. But then what would success be? If we only report success once for each successful request, is this fair? Well yes it is. It's only analogous to resending a packet in TCP. *Provided that* we count the resend as well. In other words, every time we get a RejectedOverload we should report that as a failure, and every time we get a completion other than a timeout or a local RejectedOverload we should report that as a success. EVEN IF we have already received a non-local RejectedOverload on that request. This most closely tracks the TCP metaphor: it corresponds to packet retransmission. So much for window size; what about round trip time? Strictly speaking we would use the time for the packet retransmit; the time from the local RejectedOverload to the success. However this is not appropriate because we do not resend the request from the source; therefore strict adherence would be stretching the metaphor too far. So the solution? Since a request may trigger a retransmit (meaning the request continuing after the first RejectedOverload), include the time taken by all requests which don't actually time out on the round trip time counter. -- Matthew J Toseland - toad at amphibian.dyndns.org Freenet Project Official Codemonkey - http://freenetproject.org/ ICTHUS - Nothing is impossible. Our Boss says so. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20060412/61c9a29b/attachment.pgp>
