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

Hi Ingemar,

This is a good point. I’ll add some words to Section 4 of the draft to give flexibility, and add this case to the analysis in draft-ietf-rmcat-rtp-cc-feedback.

Colin

> On 16 Dec 2019, at 07:07, Ingemar Johansson S <ingemar.s.johansson=40ericsson.com@dmarc.ietf.org> wrote:
> 
> Hi
>  
> One comment related to the feedback interval. Even though SCReAM manages relatively sparse feedback at moderate bitrates, I have observed that at high bitrates (50+ Mbps) the feedback interval needs to go down to ~2ms. 
> 50Mbps means ~4000 packets/s and with a 2ms feedback interval this means one feedback every 8 RTP packets which, I would say is in the same ballpark as QUIC and TCP. 
> In other words the feedback rate is much higher than every frame.
> It is possible to reduce the feedback frequency in SCReAM with an increased headroom for the congestion window and packet pacing, the drawback is however that the delay jitter can then increase.
>  
>  
> Regards
> Ingemar
>  
> From: Roni Even (A) <roni.even@huawei.com> 
> Sent: den 15 december 2019 09:00
> To: Colin Perkins <csp@csperkins.org>
> Cc: avt@ietf.org; rmcat@ietf.org
> Subject: Re: [rmcat] WGLC on draft-ietf-avtcore-cc-feedback-message-05
>  
> Hi Colin,
> The proposed text for section 4 looks OK
> Roni Even as individual
>  
> As for submitting an updated draft please wait for the end of the WGLC (end of this week)
>  
> Roni Even as co-chair of AVTCore WG
>  
> From: Colin Perkins [mailto:csp@csperkins.org <mailto:csp@csperkins.org>] 
> Sent: Thursday, December 12, 2019 9:16 PM
> To: Roni Even (A)
> Cc: avt@ietf.org <mailto:avt@ietf.org>; rmcat@ietf.org <mailto:rmcat@ietf.org>
> Subject: Re: [rmcat] WGLC on draft-ietf-avtcore-cc-feedback-message-05
>  
>  
>  
> 
> On 10 Dec 2019, at 12:52, Roni Even (A) <roni.even@huawei.com <mailto:roni.even@huawei.com>> 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 <https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-message-05#ref-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
>    guidance.
>  
>    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
>  
> Fixed.
>  
> Let us know when you want us to submit the revised draft.
> Colin
>  
>  
>  
>  
> 
> Roni Even
>  
>  
> From: avt [mailto:avt-bounces@ietf.org <mailto:avt-bounces@ietf.org>] On Behalf Of Roni Even (A)
> Sent: Thursday, December 05, 2019 9:30 AM
> To: avt@ietf.org <mailto:avt@ietf.org>
> Cc: rmcat@ietf.org <mailto:rmcat@ietf.org>
> 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
> https://csperkins.org/ <https://csperkins.org/>
> 
>  
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org <mailto:avt@ietf.org>
> https://www.ietf.org/mailman/listinfo/avt <https://www.ietf.org/mailman/listinfo/avt>

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