Yeah for sure. We definitely wanted to make this configurable as some of the behavior we were seeing might be specific to our wireless network. Also, the values we're using now are significantly higher than the current defaults. Probably high enough to be considered controversial.
We were seeing (on fairly lossy wifi) NACKs come in >2 seconds after packet loss was detected. The missing packets are obviously irrelevant that much later, but we found that if the NACKs were propagated back to the sender it would cause a dramatic drop in it's send rate. This was causing artificially low performance especially with wired participants that were able to download these "missing" packets without issue.
We set our cache to keep packets for 10 seconds (~3000 packets) to allow for cache hits on these late NACKs. We've seen surprisingly impressive improvements with these values in production. We haven't seen any issues with system resources yet, but we're keeping an eye on it.
The values we're using now are:
Reply to this email directly or view it on GitHub: