Subject: [codec] #17: Feedback and control loop?

From: "codec issue tracker" <[email-masked]>
Date: Wed, 21 Apr 2010 09:48:49 -0000

#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/>

---

From: Colin Perkins <[email-masked]>
Date: Wed, 21 Apr 2010 11:57:18 +0100

On 21 Apr 2010, at 10:48, codec issue tracker 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.
>
> 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.

My suggestion would be that you specify how the codec can adapt based  
on the feedback that RTP/RTCP, and its various extensions, can  
provide. More on the style of "if you have this information, this is  
how you can adapt" than "you must use this information to adapt in  
this way".

-- 
Colin Perkins
http://csperkins.org/

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 30 Apr 2010 08:34:22 -0600

On Apr 21, 2010, at 4:57 AM, Colin Perkins wrote:

>> .
> 
> 
> My suggestion would be that you specify how the codec can adapt based on the feedback that RTP/RTCP, and its various extensions, can provide. More on the style of "if you have this information, this is how you can adapt" than "you must use this information to adapt in this way".

+1 

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html