toad wrote: > If there is no RTT measurement, then how does it work? It only does the > additive increase multiplicative decrease part, on the rate of sending > requests?
Right. The node keeps locally generated searches in a queue. There's no limit on how quickly searches can be added to the queue, but there's an enforced delay between releasing searches from the queue. The enforced delay is 1/r, where r (the search rate) is additively increased whenever a search succeeds and multiplicatively decreased whenever a search fails. When the throttle's disabled, locally generated searches are processed immediately. > Can > you compare this with the current algorithm, which includes the RTT? It > may be that your simplified algorithm is better than the strict copy of > TCP which is currently deployed (which measures the RTT). Will do. Could you give me a quick idea of what RTT means in this context? Do you measure the time between generating the search and receiving a reply, or between sending the search and receiving a reply? Do searches that time out or otherwise fail count towards the RTT? Thanks, Michael
