Greetings
I hope this is the right place to ask this. (And I hope that I haven't just double posted 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
