Henning is right in that TFRC is intended for streaming protocols. My understanding is that there has been some consensus at applying it to other protocols, but it is a bit of a stretch. I'm not sure I agree with Henning's analysis, though I haven't spent enough time with it to fully understand all the implications. Didn't 5348 address the issue with data-limited senders and bursty data?
Here is literally what 5405 says: ------------ Applications that perform bulk transmission of data to a peer over UDP, i.e., applications that exchange more than a small number of UDP datagrams per RTT, SHOULD implement TCP-Friendly Rate Control (TFRC) [RFC5348], window-based, TCP-like congestion control, or otherwise ensure that the application complies with the congestion control principles. -------------- I'm a bit unclear what would be considered acceptable under the "window-based, TCP-like congestion control" part of that statement. I would think that AIMD window-based congestion control would be sufficient. Bruce On Mon, Apr 6, 2009 at 5:00 PM, Henning Schulzrinne <[email protected]> wrote: > It's not fatal, but it will essentially mean that TFRC will stay at the > initial (RFC 3390) rate for almost all transfers. The problem is that TFRC > is based on estimating loss rates, based on 8 loss intervals. If you have a > loss rate of 1%, this translates, very roughly, into 800 packets or roughly > 800 kB, before you can reliably estimate a better (higher) rate. Lower rates > will kick in sooner, since you'll get the loss intervals more quickly. > > I have to admit I'm confused as to why TFRC is seen as attractive for this > application. The main benefit, smoothing rates, is of no importance for this > application, and TFRC is significantly more complicated than the TCP > mechanism. RFC 5348 (TFRC) only specifies a mechanism, so we still would > have to engineer a new transport protocol, including reliability and the > bits necessary to do round-trip time estimation (a necessary ingredient for > TFRC as well as more classical TCP). > > Thus, saying "just use TFRC" doesn't avoid the "design transport" issue - it > just provides guidance on the congestion control algorithm, and probably is > not even the right answer for our application. > > Henning > > On Apr 6, 2009, at 1:54 PM, Brian Rosen wrote: > >> Is that a fatal flaw, or merely an expression of concern, needing some >> text? >> >> Brian >> >> >> >> From: [email protected] [mailto:[email protected]] On Behalf >> Of >> Henning Schulzrinne >> Sent: Monday, April 06, 2009 1:51 PM >> To: Saverio Mascolo >> Cc: [email protected] >> Subject: Re: [P2PSIP] Solution space for fragmentation, congestion control >> and reliability >> >> I will note that TFRC was designed for long-lived streams (e.g., media >> streams), which probably differs a bit from our typical application in >> P2PSIP, where somewhat random pairs of nodes exchange data objects of a >> few >> dozen to a few hundred packets. For example, establishing a "fair" rate is >> not trivial under those conditions, and has high error margins. >> >> Henning >> >> On Apr 6, 2009, at 1:35 PM, Saverio Mascolo wrote: >> >> >> hi lars, >> On Mon, Apr 6, 2009 at 11:20 AM, Lars Eggert <[email protected]> >> wrote: >> Hi, >> >> >> >> I'd strongly urge you to use TFRC rather than rolling your own scheme. >> Don't >> underestimate the validation effort that is required to ensure that a >> congestion control scheme is safe to deploy. This has all been done for >> TFRC, and it must be done for any new scheme. >> >> Lars >> >> is anyone aware of applications using TFRC? >> >> s >> >> _______________________________________________ >> P2PSIP mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/p2psip >> >> >> > > _______________________________________________ > P2PSIP mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/p2psip > _______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
