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

Colin Perkins <csp@csperkins.org> Wed, 21 April 2010 10:58 UTC

Return-Path: <csp@csperkins.org>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 64A823A6B49 for <codec@core3.amsl.com>; Wed, 21 Apr 2010 03:58:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.382
X-Spam-Level:
X-Spam-Status: No, score=-3.382 tagged_above=-999 required=5 tests=[AWL=0.217, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WxdjkqbTvr9C for <codec@core3.amsl.com>; Wed, 21 Apr 2010 03:57:59 -0700 (PDT)
Received: from lon1-msapost-3.mail.demon.net (lon1-msapost-3.mail.demon.net [195.173.77.182]) by core3.amsl.com (Postfix) with ESMTP id 3BA5B3A694C for <codec@ietf.org>; Wed, 21 Apr 2010 03:57:59 -0700 (PDT)
Received: from mangole.dcs.gla.ac.uk ([130.209.247.112]) by lon1-post-3.mail.demon.net with esmtpsa (AUTH csperkins-dwh) (TLSv1:AES128-SHA:128) (Exim 4.69) id 1O4XcN-0005l1-fE; Wed, 21 Apr 2010 10:57:49 +0000
Message-Id: <83E16843-6B66-4C04-A3E2-E3DAD0FB704F@csperkins.org>
From: Colin Perkins <csp@csperkins.org>
To: codec@ietf.org
In-Reply-To: <062.4d06e5df10a25734771c5c65c2b40c5c@tools.ietf.org>
Content-Type: text/plain; charset="WINDOWS-1252"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Apple Message framework v936)
Date: Wed, 21 Apr 2010 11:57:18 +0100
References: <062.4d06e5df10a25734771c5c65c2b40c5c@tools.ietf.org>
X-Mailer: Apple Mail (2.936)
Cc: trac@tools.ietf.org
Subject: Re: [codec] #17: Feedback and control loop?
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Apr 2010 10:58:00 -0000

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


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/