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

["Xiaoqing Zhu (xiaoqzhu)" <[e-mail]>]

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.