Hi,
For those of you AVT'ers interested in TFRC and its possible uses for streaming media, I released a paper earlier this month on a simulation study of TFRC with self-limiting sources such as streaming voice. The paper is available at http://www.phelan-4.com/dccp/tfrc-self-limit.pdf. Overall, the paper presents a rather bleak picture of the suitability of TFRC for voice applications.
There is an active discussion of this paper and its implications on the DCCP mailing list. At the current time, Sally Floyd is proposing some possible modifications to the TFRC algorithm, to help it work better with voice media streams. This appears promising, but the discussion of these mods is at an early stage.
Anyone with an interest is welcomed to join the discussion, of course.
Tom Phelan
-----Original Message-----
From: Ladan Gharai [mailto:ladan at isi.edu]
Sent: Thursday, October 28, 2004 11:05 AM
To: Jim Kleck
Cc: IETF AVT WG
Subject: Re: [AVT] draft-ietf-avt-tfrc-profile-03.txt - imbed feedback
in RTP?
Jim:
Thank you for your feedback - you raise a good point and actually the
ratio between data and feedback traffic is currently an open issue on
the draft, discussed in Section 9.
RFC 3350 recommends that feedback traffic not exceed %5 of the data
traffic.
However, there are combinations of data rates, RTTs and packet sizes
in which if the AVPCC profile is to abide by TFRC's (RFC
3448) feedback
requirements, then feedback traffic will exceed 5% of data traffic
For example:
a 512kbps flow with packet sizes of 50bytes and RTT=5ms, will
generate at least 140kbps of RTCP feedback (according to the current
version of the draft) - which is some what excessive and counter
intuitive to congestion control.
The same data flow with RTTs of 10ms, 20ms and 100ms
will generate
70kbps, 35kbps and 7kbps of feedback (at 14%, 6%, 1.3% of the data
traffic).
Small RTTs (<10ms) and data rates of < 1Mbps generally translate to
(depending on packet sizes) to few packets per RTT - one solution
could be to modify feedback timing requirements, such that
the ratio of
feedback to data traffic is not prohibitive in instances
where RTTs and
number of packets per RTT are relatively small.
Imbedding control traffic in the RTP packet does not present
a general
solution, because as you point out, it would only work for two-way
traffic and even in the case of two-way traffic it is generally
complicated and not always possible given TFRCs timing
requirements for
feedback.
Ladan
On Oct 27, 2004, at 3:17 PM, Jim Kleck wrote:
The draft-ietf-avt-tfrc-profile-03.txt is specifically
restricted to
unicast,
and specifies feedback possibly once per data packet. This
can generate
too much feedback traffic in the case of one-to-one video
conferencing
(which typically operates at 64K - 512K bps). However, this
case offers
a ready feedback path with much less overhead: the data pkts coming
from
the far end. An additional extension to the RTP hdr could
possibly add
the feedback at a small cost. The challenges with this scheme are:
- there is an implicit tie between the Tx and Rx RTP
sessions, but in
a one-to-one video conference that should not be too hard
to formalize
- if the app does not recv any data pkts from the farend
for a while
then
there will be no feedback, that could mean the far end has
nothing to
send
(in which case a noop RTP pkt with the feedback could be specified,
see draft-wing-avt-rtp-noop-01.txt, with no worries about
using extra
bandwidth because the lack of data makes that bandwidth
available...
or use the suggested Receiver Report extensions), or it could mean
that
there is some network problem
Does this seem worth further investigation?
Jim Kleck
8x8, Inc
_____