Greetings
I hope this is the right place to ask this.
Motivation:
I'm currently trying to implement congestion control into a Java user-space networking library suited for real-time networked games. Requirements include handling semi-volatile sized user data < MTU that are send at a fixed rate @ <= 60 Hz. I've been searching for quite some time for a suitable congestion control and believe to have finally found it - TFRC-SP.
Question:
I have been reading through the [draft](https://tools.ietf.org/html/rfc4828) and its errata and couldn't find any mention of the NDUPACK variable. [RFC 5348#Section-5.1](https://tools.ietf.org/html/rfc5348#section-5.1) talks about detection of lost packets, more specifically about marking packets as lost if the newest received packet's sequence number is at least NDUPACK higher than that old packet. NDUPACK is set to 3 by default.
I fear that this value seems a bit low for TFRC-SP, where received packets send every Min Interval (10 ms) could get reordered by more than 3 positions quite easily. Would it make sense to make NDUPACK a function of RTTVar instead (e.g. as described in [RFC 6298#2.3](https://tools.ietf.org/html/rfc6298))?
On the other hand RFC 5348 describes that previous packets marked lost can be unmarked a posteriori once the sequence number for that packet has been received. However, that requires recomputing the loss event rate.
Should I just recalculate the loss event rate afterwards or make my immediate loss event rates more accurate by depending on RTTVar? If the latter applies, what would be some sensible values?
Regards
mucaho
