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
