Subject: RE: [AVT] draft-ietf-avt-tfrc-profile-03.txt - imbed feedback in RTP?

From: "Phelan, Tom" <[email-masked]>
Date: Fri, 29 Oct 2004 10:14:25 -0400

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:[email-masked]]
> 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
> >
> >
> > _______________________________________________
> > Audio/Video Transport Working Group
> > [email-masked]
> > https://www1.ietf.org/mailman/listinfo/avt
> >
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Abdelbasset Trad <[email-masked]>
Date: Fri, 29 Oct 2004 17:13:37 +0200

Hi,
I am interested by this topic, I  have proposed a scheme: TFRC for RTP 
audio packets with variable size (using RTP packet multiplexing at an 
IP-telephony GW). Here is my paper:
   http://www-sop.inria.fr/planete/atrad/paper-icn04-trad.pdf
Cheers,
Abdelbasset Trad

Phelan, Tom wrote:

>>>_____

-- 

------------------------------------------
   Abdelbasset TRAD
   INRIA Planete Project
   2004 Route des Lucioles, BP-93
   06902 Sophia-Antipolis Cedex, France
   Phone: (+33) 4 92 38 50 22
   Fax: (+33) 4 92 38 79 78
   Email: [email-masked]
   http://www-sop.inria.fr/planete/atrad
------------------------------------------