I am sorry, but I have been retired for some years now, and am not able to deal with this.
My apologies - - Sally http://www.icir.org/floyd/ > On Apr 7, 2016, at 11:27 PM, anonymous <muc...@yahoo.com> wrote: > > 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
