[codec] #17: Feedback and control loop?

["codec issue tracker" <[e-mail]>]

#17: Feedback and control loop?
------------------------------------+---------------------------------------
 Reporter:  hoene@…                 |       Owner:     
     Type:  enhancement             |      Status:  new
 Priority:  minor                   |   Milestone:     
Component:  requirements            |     Version:     
 Severity:  Active WG Document      |    Keywords:     
------------------------------------+---------------------------------------
 On 04/13/2010 11:35 AM, Christian Hoene wrote:
 >
 > The other thing that will get difficult is to support rate control and
 > feedback loops. Especially, the feedback mechanism of RTCP are not
 > very good. It has every high overhead and it is allowed only every 5s.
 That is be fine with multicast, but in case of interactive scenarios (and
 potential feedback loops within a bidirectional codec) a bit of overkill
 and too imprecise.

 No, with unicast RTP, the minimum is 360 divided by the session bandwidth
 in kilobits/second (RFC 3550 section 6.2), with the first RTCP packet sent
 immediately.  Even for multicast the value can be reduced for active
 senders.

 RTP/(S)AVPF can use immediate feedback which seems to be what you need
 here.

 COLIN: RTCP provides relatively low-rate feedback suitable for rate
 adaptation, to avoid persistent congestion, and to provide codec control
 functions. RTCP can't, in general, provide a fast (per-RTT) feedback loop.
 If you need such rapid adaptation, you should run RTP over a congestion
 controlled transport protocol, such as TCP or DCCP, and adjust the sending
 rate based on the transport layer feedback.

 BOTZKO: (b) Feedback - messages related to QOS, packet loss, etc are what
 I mean by this.  This should be done in RTCP, though given the lack of
 VOIP support perhaps there should be a SIP INFO backup path.  Feedback
 should not be done with RTP.
 (c) Control - Per RFC 3551, RTCP can be used for "loosely controlled"
 sessions, but "may be fully or partially subsumed by a separate session
 control protocol".  Given the statements on RTCP support in the VOIP
 infrastructure, we should be careful about putting unique controls in
 RTCP.  However, it should not be done in RTP.  Since most other audio
 codecs don't require this stuff, I suspect we won't either.  Though we
 will see...

 SHPOUNT: RTCP is almost universally not implemented. The biggest VoIP
 gateway on the market does not generate RTCP. If we will rely on any RTCP
 functionality for bandwidth control it will probably be ignored.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/codec/trac/ticket/17>
codec <http://tools.ietf.org/codec/>