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

[Ladan Gharai <ladan at isi.edu>]

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
> avt at ietf.org
> https://www1.ietf.org/mailman/listinfo/avt


_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt