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

[Ines Robles <[e-mail]>]

Hi Xiaoqing,

Thanks a lot for the clarifications, I agree with your comments.

Best Regards,

Ines.

On Thu, Feb 21, 2019 at 8:46 PM Xiaoqing Zhu (xiaoqzhu) <[e-mail]>
wrote:

> 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.
>
>
>
>