"TCP-like" is presumably something like the Reno, Tahoe, Vegas or
similar variations of AIMD implemented by TCP.
I don't think you advocated this, but implementing both TFRC and AIMD
(running at the same time, not alternatives as in DCCP) seems
difficult and far more complicated.
The issue of data-limited senders has nothing to do with the start-up
issue I mentioned in my message. The inherent problem of TFRC is that
it relies on estimating a loss rate, and this, by its very nature,
takes a while unless loss are very high (which you obviously don't
want). This isn't a problem in steady state for long-lived flows, such
as a video stream, but P2PSIP does not match this model.
I agree that an AIMD mechanism (of which TCP is an instance) is
probably the better choice for this application. TFRC is neither
simpler nor "better" than AIMD, it just fits the unreliable transport
model better (again, which is not what we need here). After all, TFRC
is attempting to model AIMD behavior.
However, using AIMD means implementing the same thing as "TCP over
UDP", with maybe the header bits re-arranged, as AIMD needs much of
the TCP header information, for example.
This also has nothing to do with whether TCP can be used for real-time
data, which is probably a topic of interest to working groups other
than P2PSIP. Salman and I, with others, have a paper on this topic in
SIGMETRICS, if you happen to care about this topic.
Henning
On Apr 6, 2009, at 11:14 PM, Bruce Lowekamp wrote:
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
