Quoting Mark Handley:
| 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.
Thanks a lot for this feedback. I will change the patch once again so that the
configuration option scales in units of 100 milliseconds - that will give users
a chance to test at different granularity:
* 0 means use RFC 3448 as before
* 1 means 100 milliseconds
* 10 corresponds to the TCP timeout of 1 sec
* ...
Gerrit
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
