Re: [Gen-art] Genart last call review of draft-ietf-rmcat-video-traffic-model-06

Ines Robles <mariainesrobles@googlemail.com> Thu, 21 February 2019 19:46 UTC

Return-Path: <mariainesrobles@googlemail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C46AA130E6D; Thu, 21 Feb 2019 11:46:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=googlemail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bIsdFWVW7GcJ; Thu, 21 Feb 2019 11:46:26 -0800 (PST)
Received: from mail-ed1-x533.google.com (mail-ed1-x533.google.com [IPv6:2a00:1450:4864:20::533]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A7FEC130DBE; Thu, 21 Feb 2019 11:46:26 -0800 (PST)
Received: by mail-ed1-x533.google.com with SMTP id g19so15210883edp.2; Thu, 21 Feb 2019 11:46:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=s8buWTRjX1dtkHISddOCyUFjl/L1lgXPM9eH/ttYWwM=; b=UuTLOtx0HgUopwJFZutGNZ0XU2cuhr7BVKbQ5GYgtmU1AIVucbELA6QSU/HfQ4jQpW UCIUE3uhVs3gDvPA95BO34OzUy7zXWK9BbeCnDR9HfixlOTj+vxXQbwwzCAM49u3BBrR 7Ot3nIho4sO+c1g//LKhOSlNtiAYUvRqR8EHug3tNhwlpJHLdqg6vinFn1x/nKMcaf1W yTE3wbY3XDRr1YmS1leRoZd6jQl0rzjKMnB9lCLn0yyLKDn0JA2mJN2IoBlEevT2KTzT z455DhASJHP6Ai/mbafNQLvv4/XPjxqgqvHOGoPA2Wm1HSWvw5zc+PL3BFKFQf1qq+LV pvag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=s8buWTRjX1dtkHISddOCyUFjl/L1lgXPM9eH/ttYWwM=; b=hZOxDPk7XdG7lmouv+2A57CPVHp6xDu0VaYhIFE3rYMUrxM4GV37nFCmXRthSCwciF D51tmjOQKRGcwVkPMz7Mf8x+JSX/McEvWoFc+J03I8rW25blCnAUHnwjX5LxsLKXOG5c vADfzlSvuG1GU/xz/L9u3COKf/1ZBuLUsvftGBUZ3Pruec3k4AToL73/ZnVJFHmse++X pkENFTQlAcMpy7K8AwSXr9ruRiLrYObm4CXl04bfTzkT/Pxp8B3X8LioSH07EuH9DwRl rVKpvJqarS5BlZz9Xp4plmpwbgzLLpReys8XehiPhxO2+ovDrqN7KCvkMQt2NFhu4ZD0 Sq6g==
X-Gm-Message-State: AHQUAuYHOFer09jhyE0dgf4ubGxkTYuTbmVbtCdsjVcDb9f9IN4jxhax l9f6XY3Kx8RzGI/w8XYMruSe3TyT4Sh0GhS0pu0=
X-Google-Smtp-Source: AHgI3Iaq/7F9ZKNkINYrRLiNxrnclugvS+Xv5GFNO3JYdSKn+2S41mUQTziNMavdciw98rLqvgPwCGrgULkUGNNM5nw=
X-Received: by 2002:a50:b4f1:: with SMTP id x46mr125519edd.289.1550778384669; Thu, 21 Feb 2019 11:46:24 -0800 (PST)
MIME-Version: 1.0
References: <154836059538.29291.9954930741127591863@ietfa.amsl.com> <88D57E57-648C-4E24-A50E-790D9187B650@cisco.com>
In-Reply-To: <88D57E57-648C-4E24-A50E-790D9187B650@cisco.com>
From: Ines Robles <mariainesrobles@googlemail.com>
Date: Thu, 21 Feb 2019 21:46:12 +0200
Message-ID: <CAP+sJUe+UOT6D=h+k-V=jBBT=xcDo2NyFJZdm1U7-RD+NimnWw@mail.gmail.com>
To: "Xiaoqing Zhu (xiaoqzhu)" <xiaoqzhu@cisco.com>
Cc: "gen-art@ietf.org" <gen-art@ietf.org>, "rmcat@ietf.org" <rmcat@ietf.org>, "draft-ietf-rmcat-video-traffic-model.all@ietf.org" <draft-ietf-rmcat-video-traffic-model.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000be617805826cba19"
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/fl60ksdR8_DadyeSgDSncSY0NSw>
Subject: Re: [Gen-art] Genart last call review of draft-ietf-rmcat-video-traffic-model-06
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 21 Feb 2019 19:46:30 -0000

Hi Xiaoqing,

Thanks a lot for the clarifications, I agree with your comments.

Best Regards,

Ines.

On Thu, Feb 21, 2019 at 8:46 PM Xiaoqing Zhu (xiaoqzhu) <xiaoqzhu@cisco.com>;
wrote:

> Hi, Ines,
>
> Thanks a lot for your thorough review of this draft. We've updated to
> version -07 to
> incorporate your review comments.  More detailed response inline below
> (tagged [XZ]).
>
> Best,
> Xiaoqing (on behalf of all authors).
>
> On 1/24/19, 2:10 PM, "Ines Robles" <mariainesrobles@googlemail.com>;
> wrote:
>
>     Reviewer: Ines Robles
>     Review result: Ready
>
>     I am the assigned Gen-ART reviewer for this draft. The General Area
>     Review Team (Gen-ART) reviews all IETF documents being processed
>     by the IESG for the IETF Chair.  Please treat these comments just
>     like any other last call comments.
>
>     For more information, please see the FAQ at
>
>     <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>;.
>
>     Document: draft-ietf-rmcat-video-traffic-model-06
>     Reviewer: Ines Robles
>     Review Date: 2019-01-24
>     IETF LC End Date: 2019-01-28
>     IESG Telechat date: Not scheduled for a telechat
>
>     Summary:
>
>     I believe the draft is technically good. This document is well written
> and
>     clear to understand.
>
>     This document describes two reference video traffic models for
> evaluating RTP
>     congestion control algorithms.  The first model statistically
> characterizes the
>     behavior of a live video encoder in response to changing requests on
> target
>     video rate.  The second model is trace-driven, and emulates the output
> of
>     actual encoded video frame sizes from a high-resolution test
> sequence.  The
>     document describes also how both approaches can be combined into a
> hybrid model.
>
>     Additionally, The stand-alone traffic source module is available as an
> open
>     source implementation, which I think it is very nice. :)
>
>     I did not find issues. I have some minor questions/suggestions.
>
>     Major issues: Not found
>
>     Minor issues: Not found
>
>     Nits/editorial comments:
>
>     - Page 14: correponding -> corresponding
>
> [XZ]  Thanks for the catch! Fixed.
>
>
>     - steady state, sometimes appears as steady-state, it would be nice to
> unify
>     these terms.
>
> [XZ] Thanks for pointing this out. We've completed one pass of purging to
> stick
> to "steady state" throughout. The only two excepts are out of grammatical
> considerations ("steady-state behavior" as in "five-year-old boy").
>
>     Some Questions/suggestions:
>
>     1- In Figure 1, would it be correct to add an input as a self-loop
> arrow
>     indicating "dummy video frames"? (As previously was an input "raw
> video frames"
>     e.g. in version 4 )
>
> [XZ] We actually chose to take off the input of “raw video frames“ from
> version -04 since
> the synthetic video source does not need to perform any encoding process.
> Instead, it just
> needs to keep track of frame size and intervals, and generate dummy
> encoded video frames
> as output.  To clarify, the output label has been revised to “dummy
> encoded video frames”
>
>
>     2- Would it be correct to add in:
>
>     2.1- Page 14: "...ongoing, steady-state behavior of a video..." =>
> "...ongoing,
>     steady-state behavior (fluctuation around a constant target rate) of a
>     video..."? [1]
>
> [XZ] Thanks a lot for the suggestion. This sentence is now revised as
> follows:
>
>    In general, the trace-driven model is more realistic for mimicking
>    the ongoing, steady-state behavior of a video traffic source with
>    fluctuations around a constant target rate.  In contrast, the
>    statistical model is more versatile for simulating the behavior of a
>    video stream in transient, such as when encountering sudden rate
>    changes.
>
>     2.2 - Page 8: "...is considered to be in a transient state...." =>
> "...is
>     considered to be in a transient state (reaction to abrupt changes in
> target
>     rate)...."? [1]
>
>     [1] Based in
>
> https://datatracker.ietf.org/meeting/101/materials/slides-101-rmcat-rmcat-video-traffic-model-00
>     - Slide 2
>
> [XZ]  This has been revised accordingly as well, as follows:
>
>   The output bitrate R_o during the period [t, t+tau_v] is considered
>    to be in a transient state when reacting to abrupt changes in target
>    rate.
>
>     3- Would it be correct to add in the Figure 3 something like?:
>
>     - R_v > R_v_previous for transient state
>
>     - R_v <= R_v_previous for steady state
>
> [XZ]  Thanks for this suggestion. However, adding the R_v > R_v_previous
> in the figure would not accurately reflect the criteria we’ve observed from
> the  trace data we’ve collected (see reference [IETF-Interim]).  In fact,
> I double
> checked on our trace data, and noticed that transient behavior is observed
> in the presence of rate change in both directions (e.g., +/-20%).  I have
> revised
> the text accordingly:
>
> As shown in Figure 3, the video traffic model operates in a transient
>    state if the requested target rate R_v is substantially different
>    from the previous target, or else it operates in steady state.
> ...
> One example criterion for determining whether the
>    traffic model should operate in a transient state is whether the rate
>    change exceeds 10% of the previous target rate. ...
>
>
>
>     Thanks for this document,
>
>     Ines.
>
>
>
>