Re: [rmcat] Genart last call review of draft-ietf-rmcat-wireless-tests-08
Gyan Mishra <hayabusagsm@gmail.com> Thu, 05 March 2020 22:17 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 57C8C3A0D23; Thu, 5 Mar 2020 14:17:28 -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 a2XBoyqvM6SH; Thu, 5 Mar 2020 14:17:25 -0800 (PST)
Received: from mail-il1-x132.google.com (mail-il1-x132.google.com [IPv6:2607:f8b0:4864:20::132]) (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 4C13D3A0D21; Thu, 5 Mar 2020 14:17:25 -0800 (PST)
Received: by mail-il1-x132.google.com with SMTP id x2so189949ila.9; Thu, 05 Mar 2020 14:17:25 -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=dXbc6ncRJrXPsC/wKLTuOcNz4nKbGgU3bXPjMvohUrc=; b=tV9ildruTBY8LCMsiRkBbuWtISYs4YhljIogOMef1ZVuHcq5+34uhD6rg1aCYlC86K 0Re0UXPRIUQ1asf9KXcDhj1yTzI6ExECNy8Od2twTZmKTsHbW3yBHDM53Mr8Nh+G33H0 E8z8i1ZRdrraeWbK2oSeNNRnRDdtTeLIMdfG2vmrDTPdqLgKvR4yLxHSuh/HOEV5Dz3A W/+nDPppG4+EowJrCatN3rlIGBjj5tsVD1Ps79LOppgVjth04f30/UH+rAGF4XzrAa46 Sbkv4e3IcP8IZCZIqtP0KHIbo7Clsg1DIPcoD4gHh7r7LhZ1/0XZi3InCQmBCBrUp9zR 8UrQ==
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=dXbc6ncRJrXPsC/wKLTuOcNz4nKbGgU3bXPjMvohUrc=; b=BZ6Pl1gmAvzeqU94n63RTOLSjegBm6mO/BHa6CmaZ2A4xNCu0fKO9rKNpcLxurtzmq vh3sGEbPOEU/lXJ3ml44hgODBksczH4dfLcxvQhgR+iTiY32iGIckrh3LmnVIo6S6pzv fLRX36G0YecBrVZYnpBrb8B3QeOqRMq0o4HqRLT8yFJzXscgJ8H6HGvsTHA5c7qBjy75 ANR7KsqsIMk4QwrBgP37hfGt2KKoXgXhuVjf4hU3MX6HRdTVJuD6fsdjqFDI1loBgpQ7 18Ruxd8ItR3xR7C3gn9uP+HpJCrtypr2s8XIfyzJJs1Za+/sHjlImveDNZtIKxpDpT44 cxqQ==
X-Gm-Message-State: ANhLgQ0P47BTu3KpeyrhRg2iqVXB4s2+nxkZSORfg0FME8VjO+NoYJ0x zIhZQJ3HsSuWl+GxnrHAeTiseczdUwlkZQtFICwPoZpj
X-Google-Smtp-Source: ADFU+vtq3cTUReGQdrvoyxjwtTHqJUv246t3PIJBS0tPXNJLNv7ivp6hB+fnyOVZwBFsBjNuROqHe8hXG4aP1UgDCyQ=
X-Received: by 2002:a92:4e:: with SMTP id 75mr224665ila.276.1583446644395; Thu, 05 Mar 2020 14:17:24 -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, 05 Mar 2020 17:17:13 -0500
Message-ID: <CABNhwV0pmUrvk2f4b+hKKnyeSg48u2xNd7vWgwcNo1zN2uu43A@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="000000000000c294fd05a022e6db"
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/6TzX7nRvuNwns8-TDa4cYs6TPuM>
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:17:29 -0000
Thank you 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
- [rmcat] Genart last call review of draft-ietf-rmc… Gyan Mishra via Datatracker
- Re: [rmcat] Genart last call review of draft-ietf… Xiaoqing Zhu (xiaoqzhu)
- Re: [rmcat] [Gen-art] Genart last call review of … Alissa Cooper
- Re: [rmcat] Genart last call review of draft-ietf… Gyan Mishra
- Re: [rmcat] Genart last call review of draft-ietf… Gyan Mishra