Re: [rmcat] Genart last call review of draft-ietf-rmcat-wireless-tests-08

Gyan Mishra <hayabusagsm@gmail.com> Thu, 05 March 2020 22:26 UTC

Return-Path: <hayabusagsm@gmail.com>
X-Original-To: rmcat@ietfa.amsl.com
Delivered-To: rmcat@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C577B3A0D4C; Thu, 5 Mar 2020 14:26:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, 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=gmail.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 XysbxSK5t35E; Thu, 5 Mar 2020 14:26:34 -0800 (PST)
Received: from mail-io1-xd29.google.com (mail-io1-xd29.google.com [IPv6:2607:f8b0:4864:20::d29]) (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 0237D3A0D47; Thu, 5 Mar 2020 14:26:33 -0800 (PST)
Received: by mail-io1-xd29.google.com with SMTP id f3so123638ioc.13; Thu, 05 Mar 2020 14:26:33 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=ep3Z52xtN2/Qn5QOh/u8FlFznVE4P8eBq/i7DxsInPg=; b=Qjz5C/P/qzGjW00jjLqeP82DA/SAhYaDsOmU8JDnrKj8kDhrT7Qh+X1mJ3FuNyV/uv 7SDHKFbviHtVppUdBYQivs8PoH2ZLWovfVlNtaKOFkrhw6M0/HGbCNKLbFIToWzDKWtB b2J44Utey/cZx7KAfoa//zZFQqw6z48J1M0TfWVyZKugtEd49sAkVk9HvtCi/Q3rJOZZ vPx22u+sE9OYiwW5EMnsZlSH+Mn78OArjyKvqXJ3s8yk3W9LTKdTVlJhZbKqjp8aJfZa R6YOgc3NGMMMhhT7glxBIy8UYOKEn+SorCgq/NRTsif9ok6ewKm16at99QxucaTFNvXU +uqw==
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=ep3Z52xtN2/Qn5QOh/u8FlFznVE4P8eBq/i7DxsInPg=; b=HPIvb9gV8naVjACK3WxOAX8pIa6SX0si3FsPhtmc+JIzqun4FRbVJveRLzN79eTRcU yHIubpTHJq8hyeooQxJIaMbrmmwzq8X5ziejwbDjC8b/n40c/ZgtUOy9v1p+mwpBNp+n N3Y8dsOpC9XxHkiNvA31pYdq0vEc1X4bwd/MJvKeWVTlY+grkXgB+DClGe18EWoQ5/tb 0cWjifjM+yCyHHmuK582/AM/rkzwQtW6beiMib46EkKOdAHB6IrHAt1LQE/Fd0X1/Y41 Pdjp8Vj0Abtjp5GIcBub/uTmJp0/YGHOTBMkI5Wc4fKz6dkp1q1QSIyt6DLgA2HX236r sa+A==
X-Gm-Message-State: ANhLgQ1TuXbOhynI1ReiW4ftWoRlOYI43lEwojpJ48UWEUDhsKazD2Eg LPlLagAHAlvu2iVYtENgsQczEaGcHi/xZLKZ2Tc=
X-Google-Smtp-Source: =?utf-8?q?ADFU+vsq5XK4nl/nrpRIz79UA8ba96/PK0DCKPh4/g06?= =?utf-8?q?Wg8P5KHDIElEjEXGgFdxLSEPSWf1NwgKmGdomDwLljNyobg=3D?=
X-Received: by 2002:a6b:e310:: with SMTP id u16mr531224ioc.43.1583447193213; Thu, 05 Mar 2020 14:26:33 -0800 (PST)
MIME-Version: 1.0
References: <157965034086.28971.6105777873164080956@ietfa.amsl.com> <D86FE41A-2260-47C3-97F9-B72ACC1C5886@cisco.com>
In-Reply-To: <D86FE41A-2260-47C3-97F9-B72ACC1C5886@cisco.com>
From: Gyan Mishra <hayabusagsm@gmail.com>
Date: Thu, 5 Mar 2020 17:26:22 -0500
Message-ID: <CABNhwV0Knd+N0J16iC-Jxqbb9xYwP2XisW2xUC=gMtuPnhCing@mail.gmail.com>
To: "Xiaoqing Zhu (xiaoqzhu)" <xiaoqzhu@cisco.com>
Cc: "draft-ietf-rmcat-wireless-tests.all@ietf.org" <draft-ietf-rmcat-wireless-tests.all@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>, "rmcat@ietf.org" <rmcat@ietf.org>
Content-Type: multipart/alternative; boundary="00000000000078e2a205a023075b"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/kw2Ia9Xi7gye0lG_mz2o90U1mfM>
Subject: Re: [rmcat] Genart last call review of draft-ietf-rmcat-wireless-tests-08
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "RTP Media Congestion Avoidance Techniques \(RMCAT\) Working Group discussion list." <rmcat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rmcat>, <mailto:rmcat-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rmcat/>
List-Post: <mailto:rmcat@ietf.org>
List-Help: <mailto:rmcat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rmcat>, <mailto:rmcat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Mar 2020 22:26:37 -0000

Xiaoqing & authors

I am all set with the authors comments and responses.

Warm regards

Gyan

On Thu, Feb 27, 2020 at 12:36 PM Xiaoqing Zhu (xiaoqzhu) <xiaoqzhu@cisco.com>
wrote:

> Hi Gyan,
>
> Thanks a lot for your very thorough review of this draft, and for your
> valuable comments. We have uploaded the revised version (-09) to address
> some of the concerns and suggestions you've raised.
>
> Please also see our replies below inline, tagged [authors].  Let us know
> if you have any further thoughts or comments __
>
> Best Regards,
> Xiaoqing, on behalf of all authors.
>
>
> On 1/21/20, 3:46 PM, "Gyan Mishra via Datatracker" <noreply@ietf.org>
> wrote:
>
>     Reviewer: Gyan Mishra
>     Review result: Ready with Issues
>
>     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>.
>
>     Reviewer: Gyan Mishra
>     Review result: Ready with Minor Issues
>
>     Document: draft-ietf-rmcat-wireless-tests-08
>     Reviewer: Gyan Mishra
>     Review Date: 2020-01-17
>     IETF LC End Date: 2020-01-21
>     IESG Telechat date: Not scheduled for a telechat
>
>     Summary: Ready, but with nits and minor issues that should be
> addressed.
>
>     Major issues: None
>
>     Minor issues:  This document describes test cases for evaluating
> performance of
>     RTP congestion control algorithms over LTE & WIFI networks.
>
>     Section 1 It is mentioned a number of instance where “wired” is
> mentioned where
>     I believe “wireless” or “WIFI” is what is meant to be stated.  Please
> check.
>
> [authors] Thanks for raising this concern. We’ve doubled checked on the
> usage of “wired” in all three instances in the introduction section, and
> believe it is intended as such.  Our intention was to contrast the
> characteristics of wireless networks from those of wired networks, as a
> motivation of the need for this draft.   We have, however, taken the
> opportunity to revise those sentences to make them less wordy.
>
>     I would recommend  to use WIFI to refer to local LAN WIFI and use
> cellular to
>     refer to a mobile handset, and not use the term “wireless” as that
> could be
>     confusing.
>
> [authors] We agree with the suggestion that it is preferable to refer
> specifically to WiFi or cellular whenever possible and have mostly edited
> out the word “wireless”. In a few places, however, it is rather cumbersome
> to always say “cellular and WiFi networks” when our intention is to simply
> contrast the difference between wireless and wired communication. We have
> therefore stuck with the term “wireless” in those cases.
>
>     I would recommend not using LTE to refer to Cellular from a general
> mobile
>     handset point of view, since LTE refers to 4G and Cellular could be
> any -
>     2G,3G,4G,5G etc
>
> [authors]  We agree with this proposed change. The text has been updated
> accordingly with a few exceptions: a) mentioning LTE/5G as an example of
> operational cellular network; b) pointing to the LTE simulator in NS-3; and
> c) referencing the corresponding 3GPP standard documents.
>
>     Section 3 This section also mentioned “wired” where I think the goal
> of the
>     document is test cases of WIFI & Cellular and adding in wired does
> confuse the
>     reader as we are talking about quality degradation issues with wireless
>     technologies - WIFI & Cellular.  Please check the verbiage.
>
> [authors] Thanks for pointing this out. We have checked all three previous
> usage of the word in this section and have eliminated the mention of it in
> the introductory discussions. The remaining two uses, however, are needed
> for describing the proposed test case topology so we left them as is.
>
>     Section 3 In this sentence you mention 3G support of high bandwidth.
> My
>     experience with 3G has not been very slow page loading and that
> multimedia
>     would suffer.
>
> [authors] This is a fair complaint. To avoid controversy, we have revised
> the sentence to now state: “… it is evident that only the more recent radio
> technologies can support the high bandwidth requirements  …”
>
>
>     Section 3 Bottom of page 5 it is mentioned that the combination of
> multiple
>     access technologies such as one user has LTE connection and another
> has Wi-Fi
>     connection is kept out of the scope of this document.  Please explain
> why as
>     the reader would believe it would be in scope as that is the main
> topic.
>
> [authors]  When some of the users are on LTE and some of the users are on
> Wi-Fi, it is only interesting to investigate the test case when the
> bottleneck of the system is on the wired hop.  Whereas the main focus of
> this draft is to evaluate how congestion control schemes interactive over
> the wireless interface. We have added the following statement in the draft
> to explain why it is out of scope:
>
>         “It should be noted that the goal of the following test cases is
> to evaluate the performance
>         of candidate algorithms over the radio interface of the cellular
> network. Hence it is assumed
>         that the radio interface is the bottleneck link between the
> communicating peers and that the core
>         network does not introduce any extra congestion along the path.
> Consequently, this draft has kept
>         as out of scope the combination of multiple access technologies
> involving both cellular and Wi-Fi users.”
>
>     Section 3 Top of page 6 - I am wondering if there is a better
> explanation of
>     why you need a test simulator due to unpredictable nature or cellular
> other
>     than underground mines.
>
> [authors]  The unpredictable nature of the cellular networks makes test
> results unrepeatable. Therefore our recommendation of carrying out tests
> using simulators.
>
>     Section 3.1.1 Here the fixed user is on a wired LAN connected to
> mobile user.
>     You mention wireless interface which makes me wonder is the fixed user
> actually
>     a WIFI user connected to broadband WIFI router wired to the internet.
> See in
>     quotes which makes me wonder "The fixed user is connected to the
> Internet via
>     wired connection with sufficiently high bandwidth, for instance, 10
> Gbps, so
>     that the system is resource limited on the {wireless?} interface"
>
>
> [authors]  Thanks for raising this point of confusion. The proposed test
> case comprise of both cellular users and fixed users. They share the wired
> backhaul link with sufficiently high bandwidth.  As such, the bottleneck of
> the system is over the cellular radio access link.  We have revised the
> sentence as below to avoid further confusion:
>
> “… so that the system bottleneck is on the cellular radio access interface
> … “
>
>
>     Section 4.1 Please explain in why the home access link represents a
> bottleneck
>     due to its bandwidth. It is not obvious as these days Gigabit and above
>     broadband speeds are available at home.
>
>
> [authors] We agree that the scenario where the wired hop remains the
> bottleneck is becoming less common. This subsection describes test cases to
> reflect DSL-like home Internet access that's less common but still present
> especially in other parts of the world.   As acknowledged in this section,
> these test cases are proposed mainly as a sanity check. Over time, we can
> perhaps get rid of this section completely.
>
>     Nits/editorial comments:
>
>     Draft Date should to be updated.
>
> [authors] Done
>
>     Section 3.1.2  1-B Antenna- [2D, 3D] should be defined
>
> [authors]  The cited reference of the 3GPP test plan contains information
> for the above terminology.  For this round of revision we have not gathered
> input from authors familiar with the cellular technology terminologies. We
> will try to update the definition directly in the text in a later revision.
>
>     Section 3.1.2 RTT [40, 150] , should define a unit millisecond
>
> [authors] Done.
>     Section 3.1.2 4. User Intensity, should define what the values in
> brackets mean
>     and unit of measure.
>
> [authors]  The cited reference of the 3GPP test plan contains information
> for the above terminology.  For this round of revision we have not gathered
> input from authors familiar with the cellular technology terminologies. We
> will try to update the definition directly in the text in a later revision.
>
>  Section 3.1.2 7.2.a Media direction: Uplink and Downlink,   should define
> what is meant by Uplink and Downlink
>
> [authors] The definition has been provided in the second paragraph of
> Section 3.1.1 as well as in the illustration in Fig. 1.
>
> Section 4.2.3 g N= [4, 8,  12, 16, 20], should define what N is and any
> unit of measure
>
> [authors] The variables N and M indicate the number of real-time media
> flows and competing TCP streams, respectively, as illustrated in Fig. 2. We
> added a sentence in Sec. 4.1.1 to explicitly explain this
>
>     _______________________________________________
>
>     Gen-art mailing list
>     Gen-art@ietf.org
>     https://www.ietf.org/mailman/listinfo/gen-art
>
>
>
>
> --

Gyan  Mishra

Network Engineering & Technology

Verizon

Silver Spring, MD 20904

Phone: 301 502-1347

Email: gyan.s.mishra@verizon.com