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) <xiaoqzhu@xxxxxxxxx> 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" <mariainesrobles@xxxxxxxxxxxxxx> 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.
