Re: [rmcat] WGLC on draft-ietf-avtcore-cc-feedback-message-05

Colin Perkins <> Thu, 12 December 2019 19:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9988120088; Thu, 12 Dec 2019 11:16:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cOO36Zf0TxwU; Thu, 12 Dec 2019 11:16:32 -0800 (PST)
Received: from ( [IPv6:2a00:1098:0:82:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8AD26120024; Thu, 12 Dec 2019 11:16:32 -0800 (PST)
Received: from [] (port=53302 helo=[]) by with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92.3) (envelope-from <>) id 1ifTwo-0003EZ-SF; Thu, 12 Dec 2019 19:16:31 +0000
From: Colin Perkins <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_7CE221AC-883C-4E02-95AC-ADF01126339A"
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\))
Date: Thu, 12 Dec 2019 19:16:16 +0000
In-Reply-To: <>
Cc: "" <>, "" <>
To: Roni Even <>
References: <> <>
X-Mailer: Apple Mail (2.3445.104.11)
X-BlackCat-Spam-Score: 14
Archived-At: <>
Subject: Re: [rmcat] WGLC on draft-ietf-avtcore-cc-feedback-message-05
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 12 Dec 2019 19:16:36 -0000

> On 10 Dec 2019, at 12:52, Roni Even (A) <> wrote:
> Hi,
> Some comments as individual
> 1. in section 10 the registration of the SDP ccfb attribute need also to include mux category

That attribute is registered by draft-ietf-mmusic-sdp-mux-attributes, which include the mux category. This draft is registering a parameter within that attribute.

> 2. In section 4 it is says  “It has been shown  [I-D.ietf-rmcat-rtp-cc-feedback <>] that in most cases a per frame feedback is a reasonable assumption on how frequent the RTCP feedback messages can be transmitted.“ later in the section it talks about 50-200msec and say that a value in this range need to be negotiated.  Looking at rmcat-rtp-cc-feedback I got the impression that a report per frame is recommended. 

I rephrased the section to:

   There is a trade-off between speed and accuracy of reporting, and the
   overhead of the reports.  [I-D.ietf-rmcat-rtp-cc-feedback] discusses
   this trade-off, suggests desirable RTCP feedback rates, and provides
   guidance on how to configure the RTCP bandwidth fraction, etc., to
   make appropriate use of the reporting block described in this memo.
   Specifications for RTP congestion control algorithms can also provide

   It is generally understood that congestion control algorithms work
   better with more frequent feedback.  However, RTCP bandwidth and
   transmission rules put some upper limits on how frequently the RTCP
   feedback messages can be sent from an RTP receiver to the RTP sender.
   It has been shown [I-D.ietf-rmcat-rtp-cc-feedback] that in most cases
   sending feedback one per frame is an upper bound before the reporting
   overhead becomes excessive.  Analysis [feedback-requirements] has
   also shown that candidate congestion control algorithms can operate
   with less frequent feedback, using a feedback interval range of
   50-200ms.  Applications need to negotiate an appropriate feedback
   interval at session setup.

The draft-ietf-rmcat-rtp-cc-feedback is trying to show that per-frame feedback is possible, with acceptable overhead, but unless the codec can adapt on a per frame basis, it’s not clear that such frequent feedback is necessary. This version is intended to give bounds, and encourage people to draft draft-ietf-rmcat-rtp-cc-feedback, which will be expanded to give more discussion over time. Does this clarify?

> 3. A nit – please expand RTS at first occurrence, it is expanded a bit late


Let us know when you want us to submit the revised draft.

> Roni Even
> From: avt [ <>] On Behalf Of Roni Even (A)
> Sent: Thursday, December 05, 2019 9:30 AM
> To: <>
> Cc: <>
> Subject: [AVTCORE] WGLC on draft-ietf-avtcore-cc-feedback-message-05
> Hello, all!
> As we discussed in Singapore, this is to announce a Working Group Last Call for draft-ietf-avtcore-cc-feedback-05.
> Please review this document and send comments to the AVT mailing list by Thursday, December 19, 2019.
> If you review the document and have nothing to add, please let the list know that as well.
> Thank you!
> Roni Even 
> AVTCore co-chair

Colin Perkins