Re: [Gen-art] Genart last call review of draft-ietf-rmcat-video-traffic-model-06

["Xiaoqing Zhu (xiaoqzhu)" <[e-mail]>]

Hi, Ines, 

Thanks a lot for your thorough review of this draft. We've updated to version -07 to
incorporate your review comments.  More detailed response inline below (tagged [XZ]).

Best,
Xiaoqing (on behalf of all authors). 

On 1/24/19, 2:10 PM, "Ines Robles" <[e-mail]> wrote:

    Reviewer: Ines Robles
    Review result: Ready
    
    I am the assigned Gen-ART reviewer for this draft. The General Area
    Review Team (Gen-ART) reviews all IETF documents being processed
    by the IESG for the IETF Chair.  Please treat these comments just
    like any other last call comments.
    
    For more information, please see the FAQ at
    
    <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
    
    Document: draft-ietf-rmcat-video-traffic-model-06
    Reviewer: Ines Robles
    Review Date: 2019-01-24
    IETF LC End Date: 2019-01-28
    IESG Telechat date: Not scheduled for a telechat
    
    Summary:
    
    I believe the draft is technically good. This document is well written and
    clear to understand.
    
    This document describes two reference video traffic models for evaluating RTP
    congestion control algorithms.  The first model statistically characterizes the
    behavior of a live video encoder in response to changing requests on target
    video rate.  The second model is trace-driven, and emulates the output of
    actual encoded video frame sizes from a high-resolution test sequence.  The
    document describes also how both approaches can be combined into a hybrid model.
    
    Additionally, The stand-alone traffic source module is available as an open
    source implementation, which I think it is very nice. :)
    
    I did not find issues. I have some minor questions/suggestions.
    
    Major issues: Not found
    
    Minor issues: Not found
    
    Nits/editorial comments:
    
    - Page 14: correponding -> corresponding

[XZ]  Thanks for the catch! Fixed. 

    
    - steady state, sometimes appears as steady-state, it would be nice to unify
    these terms.
    
[XZ] Thanks for pointing this out. We've completed one pass of purging to stick
to "steady state" throughout. The only two excepts are out of grammatical 
considerations ("steady-state behavior" as in "five-year-old boy"). 

    Some Questions/suggestions:
    
    1- In Figure 1, would it be correct to add an input as a self-loop arrow
    indicating "dummy video frames"? (As previously was an input "raw video frames"
    e.g. in version 4 )
    
[XZ] We actually chose to take off the input of “raw video frames“ from version -04 since
the synthetic video source does not need to perform any encoding process. Instead, it just
needs to keep track of frame size and intervals, and generate dummy encoded video frames
as output.  To clarify, the output label has been revised to “dummy encoded video frames”


    2- Would it be correct to add in:
    
    2.1- Page 14: "...ongoing, steady-state behavior of a video..." => "...ongoing,
    steady-state behavior (fluctuation around a constant target rate) of a
    video..."? [1]

[XZ] Thanks a lot for the suggestion. This sentence is now revised as follows: 

   In general, the trace-driven model is more realistic for mimicking
   the ongoing, steady-state behavior of a video traffic source with
   fluctuations around a constant target rate.  In contrast, the
   statistical model is more versatile for simulating the behavior of a
   video stream in transient, such as when encountering sudden rate
   changes.
    
    2.2 - Page 8: "...is considered to be in a transient state...." => "...is
    considered to be in a transient state (reaction to abrupt changes in target
    rate)...."? [1]
    
    [1] Based in
    https://datatracker.ietf.org/meeting/101/materials/slides-101-rmcat-rmcat-video-traffic-model-00
    - Slide 2

[XZ]  This has been revised accordingly as well, as follows: 

  The output bitrate R_o during the period [t, t+tau_v] is considered
   to be in a transient state when reacting to abrupt changes in target
   rate.
    
    3- Would it be correct to add in the Figure 3 something like?:
    
    - R_v > R_v_previous for transient state
    
    - R_v <= R_v_previous for steady state
  
[XZ]  Thanks for this suggestion. However, adding the R_v > R_v_previous
in the figure would not accurately reflect the criteria we’ve observed from
the  trace data we’ve collected (see reference [IETF-Interim]).  In fact, I double
checked on our trace data, and noticed that transient behavior is observed 
in the presence of rate change in both directions (e.g., +/-20%).  I have revised
the text accordingly:

As shown in Figure 3, the video traffic model operates in a transient
   state if the requested target rate R_v is substantially different
   from the previous target, or else it operates in steady state.
...
One example criterion for determining whether the
   traffic model should operate in a transient state is whether the rate
   change exceeds 10% of the previous target rate. ...


  
    Thanks for this document,
    
    Ines.