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

From: Ben Campbell <[email-masked]>
Date: Tue, 05 Feb 2019 19:23:27 -0800

Ben Campbell 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:
----------------------------------------------------------------------

§3: I am a little surprised not to see much discussion of how much variation in
behavior you expect from different real-world encoders. I think the models
probably have enough knobs to handle this, but an overview discussion would be
helpful.

§6: From reading further, I understand the real-world encoder creates a library
of frames to be sent during testing. If that is correct, it would be helpful to
say a few words about it in the opening paragraphs.

§10: It's not obvious to me how the listed consideration is security related. I
am willing to believe it is, but some words to tie it to security would be
helpful.

---

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

Hi Ben, 

Thanks for reviewing our draft.  We've recently updated it to version -07 and
tried to address your comments via our revision. 

Please find more detailed responses below inline (tagged [XZ]).  Let us know if
you have any further thoughts or suggestions. 

Best,
Xiaoqing (on behalf of all authors). 

On 2/5/19, 9:23 PM, "Ben Campbell" <[email-masked]> wrote:

    

[XZ] This is a great point. There were indeed quite some discussions about variations
in real-world encoder behaviors during WG meetings. You are right that the draft
should also capture this point. We added the following text in the last paragraph of
the intro to reflect this:

"...  The synthetic traffic model should also contain tunable parameters so that
it can be flexibly adjusted to reflect the wide variations in real-world live video
encoder behaviors.   ..."

[XZ] Instead of keeping a library of frames generated by real-world encoders, 
the traces of frame size and intervals (instead of the encoded frame contents
themselves) are used to drive the trace-based model. The wording in the final
paragraph of the intro section has been revised to describe the trace-based
model more clearly:

" ... The second is driven by frame size and interval traces recorded from
a real-world encoder ..." 

[XZ] That’s a fair point and also raised by a few other reviewers.  We’ve revised
the text of the Security Considerations section in version -07, as below, to clarify
that the draft itself does not impose security concerns. Instead, the models described
herein can be used for evaluating candidate algorithms to prevent them from hurting
the Internet:
    
"The synthetic video traffic models as described in this draft do not
   impose any security threats.  They are designed to mimic realistic
   traffic patterns for evaluating candidate RTP-based congestion
   control algorithms, so as to ensure stable operations of the network.
   It is RECOMMENDED that candidate algorithms be tested using the video
   traffic models presented in this draft before wide deployment over
   the Internet.  If the generated synthetic traffic flows are sent over
   the Internet, they also need to be congestion controlled."