Hi Tommy,
Thanks a lot for reviewing our draft and providing your input. We've recently updated
the draft to version -07. Please find inline below (tagged [XZ]) on how we tried to
incorporate your comments.
Any further thoughts are always welcome!
Thanks,
Xiaoqing (on behalf of all authors)
On 2/1/19, 11:54 AM, "Tommy Pauly" <tpauly@xxxxxxxxx> wrote:
Reviewer: Tommy Pauly
Review result: Ready
This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.
When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@xxxxxxxx if you reply to or forward this review.
Document: draft-ietf-rmcat-video-traffic-model-06
This document is clearly written and provides useful guidance on how to
model live video traffic for the purpose of evaluating congestion
control algorithms.
The document is clear in its goal of not defining new protocols or
congestion control algorithms. As such, it does not pose any transport
protocol or algorithm concerns.
While I agree with the Security Area Directorate's review that the
content of "Security Considerations" does not seem to apply to security
directly, there is precedent for putting warnings to avoid congestion
collapse into the Security Considerations sections (see RFC 5681 as
an example). I am happy to see this text either remain in security
considerations or move to a new section, potentially earlier in the
document to emphasize the importance of using realistic models
for evaluating congestion control.
[XZ] Thanks for raising this concern, which is also shared by a few other reviewers.
In the new version we've revised the text in the Security Considerations section as
below, so as 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."
Very minor editorial nits:
- R_v is described first in Section 4 as the "target rate request",
but unlike most of the other definitions there is not given a unit.
Later, Section 5 shows that an example value is "1 Mbps". It is clear
that this is a "bitrate" as referred elsewhere in the document, but
it may be clearer to describe this as the "target bitrate request",
or similar. A similar comment would apply to R_o, as defined in
Section 5.2.
[XZ] Good catch. The new version (-07) now refers to R_v and R_o as “bitrate”.
We also explicitly mention the unit (bit-per-second) when first introducing these
variables.
- In Section 6.1, the document states that "it has been empirically
determined that a sequence with a length between 2 and 4 minutes
strikes a fair tradeoff [between short and long sample times]."
The lower bound on the length of a sample is determined by avoiding
"obvious periodic patterns" in the model; while the upper bound is
determined by the ability of the system or model to efficiently
store the sampled data. It seems that the lower bound here is a
stricter limit, and the upper bound may change in the future or in
other test setups depending on the capabilities of the testing
system. To that end, it may be equally useful and more future-proof
to state that "it has been empirically determined that a sequence
2 to 4 minutes in length sufficiently avoids the periodic pattern."
[XZ] Very nice point on making the draft future proof. The text has been
updated as suggested in version -07.
