[codec] #17: Feedback and control loop?

"codec issue tracker" <trac@tools.ietf.org> Wed, 21 April 2010 09:49 UTC

Return-Path: <trac@tools.ietf.org>
X-Original-To: codec@core3.amsl.com
Delivered-To: codec@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 842553A6890 for <codec@core3.amsl.com>; Wed, 21 Apr 2010 02:49:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.532
X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id U0RBsi5+dD+3 for <codec@core3.amsl.com>; Wed, 21 Apr 2010 02:49:00 -0700 (PDT)
Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6A0D13A6A7A for <codec@ietf.org>; Wed, 21 Apr 2010 02:48:58 -0700 (PDT)
Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.69) (envelope-from <trac@tools.ietf.org>) id 1O4WY5-0001Ue-GX; Wed, 21 Apr 2010 02:48:49 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: codec issue tracker <trac@tools.ietf.org>
X-Trac-Version: 0.11.6
Precedence: bulk
Auto-Submitted: auto-generated
X-Mailer: Trac 0.11.6, by Edgewall Software
To: hoene@uni-tuebingen.de
X-Trac-Project: codec
Date: Wed, 21 Apr 2010 09:48:49 -0000
X-URL: http://tools.ietf.org/codec/
X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/codec/trac/ticket/17
Message-ID: <062.4d06e5df10a25734771c5c65c2b40c5c@tools.ietf.org>
X-Trac-Ticket-ID: 17
X-SA-Exim-Connect-IP: ::1
X-SA-Exim-Rcpt-To: hoene@uni-tuebingen.de, codec@ietf.org
X-SA-Exim-Mail-From: trac@tools.ietf.org
X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false
Cc: codec@ietf.org
Subject: [codec] #17: Feedback and control loop?
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.9
Reply-To: trac@localhost.amsl.com
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 09:49:01 -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

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

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