On 12/1/06, Colin Perkins <csp@xxxxxxxxxxxxx> wrote:
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.
You make a good point. The cost of checking the timer should be fairly low if you're already in the DCCP send code for the relevant connection. You have to reset the timer anyway every time you get feedback, and checking the timer shouldn't be more expensive than resetting it. As you get feedback every RTT under normal conditions, you ought to be able to check it at least once per RTT so long as you're in the DCCP code anyway. Now, do you every need to check the timer when you're not in the DCCP send code? I think not. It's not like TCP, where you need to send a packet on RTO expiry. I think it should be possible to only ever check the nofeedback timer when you're in the send code for that particular DCCP connection. And if so, then surely you can afford to check it as often as you reset it - ie around once per RTT? You just have to be a bit smart - if you go to send and discover that the timer should have expired multiple times, then you have to process multiple backoff events, and perhaps reschedule your send for later after you've done that. - Mark
