Subject: [rmcat] Adam Roach's No Objection on draft-ietf-rmcat-video-traffic-model-06: (with COMMENT)

From: Adam Roach <[email-masked]>
Date: Tue, 05 Feb 2019 21:36:48 -0800

Adam Roach has entered the following ballot position for
draft-ietf-rmcat-video-traffic-model-06: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-rmcat-video-traffic-model/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thanks everyone who worked on this document.

As a general comment: the various discussions of intra frame generation might
benefit from a reference to the FIR behavior described in section 4.3.1 of RFC
5014. The current description seems focused on local decisions to generate
intra frames, where the sender is in control of when such frames should be
generated. It seems that receiver-requested I frames should also be considered
by any party making use of these models.

---------------------------------------------------------------------------

§3:

>  In the presence of a
>  significant change in target rate, the encoder output frame sizes
>  sometimes fluctuates for a short, transient period of time before the
>  output rate converges to the new target.

Nit: "...frame sizes sometimes fluctuate..." or "...frame size sometimes
fluctuates..."

---

From: "Xiaoqing Zhu (xiaoqzhu)" <[email-masked]>
Date: Fri, 22 Feb 2019 04:51:53 +0000

Thanks a lot for your review, Adam.   We've updated our draft to version -07 and 
have tried to incorporate your comments in our revision. 

Please find more detailed responses below in line (tagged [XZ]).  Any further comments
are always welcome. 

Best,
Xiaoqing (on behalf of all authors)

On 2/5/19, 11:37 PM, "rmcat on behalf of Adam Roach" <[email-masked] on behalf of [email-masked]> wrote:

    

    
[XZ] Good suggestion.  We added the possibility of receiver-requested I frames when
discussing “On-demand generation of intra (I) frame:” in Sec 4., as follows:

" ... This request typically comes from the error control module.  It can be
  initiated either by the sender or by the receiver via Full Intra Request (FIR)
  messages as defined in [RFC5104]. " 

    

[XZ]  Thanks for the catch!  Fixed.