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@ietf.org 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.

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.

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