hi bruce,
On Tue, Apr 7, 2009 at 5:14 AM, Bruce Lowekamp <[email protected]> wrote: > Henning is right in that TFRC is intended for streaming protocols. why tcp is not good for streaming? youtube i using TCP. do you mean tfrc for real-time? saverio > 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 >
_______________________________________________ P2PSIP mailing list [email protected] https://www.ietf.org/mailman/listinfo/p2psip
