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) <[email protected]> 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" <[email protected]> > 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. > > > >
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
