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

[Colin Perkins <[e-mail]>]

> On 10 Dec 2019, at 12:52, Roni Even (A) <[e-mail]> 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:[e-mail] <mailto:[e-mail]>] On Behalf Of Roni Even (A)
> Sent: Thursday, December 05, 2019 9:30 AM
> To: [e-mail] <mailto:[e-mail]>
> Cc: [e-mail] <mailto:[e-mail]>
> 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/