Re: [Tsv-art] Tsvart telechat review of draft-ietf-rmcat-video-traffic-model-06

[Tommy Pauly <[e-mail]>]

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) <[e-mail]> 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" <[e-mail]> 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
>    [e-mail] 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.
> 
> 
>