Thank you! I've just read his paper, and am looking forward to experiment with the concepts he introduced for shifting workload to the sender.
I've contacted him in the meantime, fingers crossed :)
In case anyone else might be interested in user-space implementations, you might want to checkout Linux kernel prototype DCCP CCID4 and CCID5 implementations [1] and GoDCCP CCID3 [2].
Regards
mucaho
On Sunday, April 10, 2016 6:17 PM, LOCHIN Emmanuel <Emmanuel.LOCHIN@xxxxxxx> wrote:
Dear Mucaho
FYI, there's a full Java implementation of TFRC done by Guillaume Jourjon in 2007 at NICTA :
https://www.nicta.com.au/category/research/mobile-systems/people/gjourjon/
You might ask him whether this implementation is still available before starting a new one.
EL
Emmanuel LOCHIN Professeur ISAE ISAE SUPAERO - Institut Supérieur de l'Aéronautique et de l'Espace 10 avenue Edouard Belin - BP 54032 - 31055 TOULOUSE CEDEX 4 FRANCE - http://www.isae-supaero.fr Tel +33 5 61 33 91 85 - Fax (+33) 5 61 33 83 30 Plan d'accès/Access map |
De: Sally Floyd <sallyfloyd@xxxxxxx>
Envoyé: 10 avr. 2016 6:46 PM
À: anonymous
Cc: dccp group
Objet: Re: TFRC-SP (RFC 4828) - Detection of Lost Packets
Envoyé: 10 avr. 2016 6:46 PM
À: anonymous
Cc: dccp group
Objet: Re: TFRC-SP (RFC 4828) - Detection of Lost Packets
I am sorry, but I have been retired for some years now, and am not able to deal with this.
My apologies -
- Sally
On Apr 7, 2016, at 11:27 PM, anonymous <mucaho@xxxxxxxxx> wrote:GreetingsI 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?Regardsmucaho
