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

From: Jim Kleck <[email-masked]>
Date: Wed, 27 Oct 2004 12:17:27 -0700

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

---

From: Ladan Gharai <[email-masked]>
Date: Thu, 28 Oct 2004 11:05:28 -0400

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