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].
Regardsmucaho [1] https://github.com/uoaerg/linux-dccp[2] https://github.com/petar/GoDCCP On Sunday, April 10, 2016 6:17 PM, LOCHIN Emmanuel <emmanuel.loc...@isae.fr> 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 #yiv9446832497 DD, #yiv9446832497 OL, #yiv9446832497 UL {padding-left:2em;}#yiv9446832497 li {padding:0.1em;}#yiv9446832497 body {background-color:white;line-height:1.2;}#yiv9446832497 blockquote.yiv9446832497airwise {border-left-style:solid;border-left-width:0.2em;font-family:Times New Roman, Times, Serif;margin:0.5em 1.2em;padding-left:1em;padding-top:0.2em;padding-bottom:0.2em;} | Emmanuel LOCHIN Professeur ISAEISAE 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 <sallyfl...@mac.com> Envoyé: 10 avr. 2016 6:46 PM À: anonymous Cc: dccp group Objet: Re: [dccp] 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 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. [RFC5348#Section-5.1](https://tools.ietf.org/html/rfc5348#section-5.1) talks about detection of lost packets, more specifically about markingpackets as lost if the newest received packet's sequence number is atleast NDUPACK higher than that old packet. NDUPACK is set to 3 bydefault. I fear that this value seems a bit low for TFRC-SP, where receivedpackets send every Min Interval (10 ms) could get reordered by more than 3 positions quite easily. Would it make sense to make NDUPACK afunction of RTTVar instead (e.g. as described in [RFC6298#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 latterapplies, what would be some sensible values? Regardsmucaho
