Hi Xiaoqing, Thanks for making the updates to the draft! The -07 version looks good. Best, Tommy > On Feb 21, 2019, at 8:25 PM, Xiaoqing Zhu (xiaoqzhu) <xiaoqzhu@xxxxxxxxx> wrote: > > 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. > > >
