On 1 Dec 2006, at 12:38, Mark Handley wrote:
I agree that running a very small no-feedback timer is a bad idea. But I think that 1 second is probably far too large. The purpose of the nofeedback timer is to slow DCCP down when there is serious network congestion. Waiting 1 second on a LAN would mean sending for thousands of RTTs before starting to slow down. And on wide-area links in places like the UK, it could be 100 RTTs before you slow down, although this would be mitigated a little if the problem was congestion, and a queue built up. My gut feeling is that there should be a lower bound on the nofeedback timer, but that 100ms would be a more appropriate value. This is motivated by an attempt to compromise between a large value for efficient DCCP implementations, and a small value to avoid disrupting the network for too long when bad stuff is happening. From a human usability point of view, you probably can cope with dropouts in audio of 100ms without it being too bad, but 1 second is too long.
I'd actually suggest something on the order of 16-20ms. The rationale would be to match the typical inter-frame interval for multimedia applications, so that the kernel will likely be processing a sent packet when the timer expires, and can amortise the costs of checking the nofeedback timer into the send routine.
Colin
