Re: [Gen-art] [rmcat] Genart last call review of draft-ietf-rmcat-nada-11

"Joel M. Halpern" <jmh@joelhalpern.com> Sun, 25 August 2019 13:35 UTC

Return-Path: <jmh@joelhalpern.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 37C3F12022E; Sun, 25 Aug 2019 06:35:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=joelhalpern.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 KqWiGAcaDU2Q; Sun, 25 Aug 2019 06:35:02 -0700 (PDT)
Received: from mailb2.tigertech.net (mailb2.tigertech.net [208.80.4.154]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6840812002E; Sun, 25 Aug 2019 06:35:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailb2.tigertech.net (Postfix) with ESMTP id 46GbjL2Gy1zXpMl; Sun, 25 Aug 2019 06:35:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joelhalpern.com; s=2.tigertech; t=1566740102; bh=6T8HyfKdFmWnOsza458EHEN/YEd+cj3ldAweIrgM4oY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=gt2KyBnRASOkpo/4sDzkjjr/Tt66C17m+eRHjdVgahpERHCNyYFga8CatxRBrCuHn xpboyg5hWeJkz4+QJemXEMFVDmarfGOPGnP4T6yd9eWARq8P6k+4RlIToolBIMXWdH fL913jINYZxSN/aiRhKCoVc7kSIlpDTdRyuO3GdM=
X-Virus-Scanned: Debian amavisd-new at b2.tigertech.net
Received: from [172.20.7.244] (209-255-163-147.ip.mcleodusa.net [209.255.163.147]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mailb2.tigertech.net (Postfix) with ESMTPSA id 46GbjK4V25zXpNQ; Sun, 25 Aug 2019 06:35:01 -0700 (PDT)
To: "Xiaoqing Zhu (xiaoqzhu)" <xiaoqzhu@cisco.com>, "gen-art@ietf.org" <gen-art@ietf.org>
Cc: "draft-ietf-rmcat-nada.all@ietf.org" <draft-ietf-rmcat-nada.all@ietf.org>
References: <156504341913.1947.3933210567772943756@ietfa.amsl.com> <34AB0964-230B-40F2-A865-08F568E72A85@cisco.com> <375e0240-1983-53e6-8e6f-d4d71c6e13c3@joelhalpern.com> <8253AE48-7084-4178-A1B1-94738215463F@cisco.com>
From: "Joel M. Halpern" <jmh@joelhalpern.com>
Message-ID: <fc14feea-0582-3030-d796-6eef40c33951@joelhalpern.com>
Date: Sun, 25 Aug 2019 09:34:57 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0
MIME-Version: 1.0
In-Reply-To: <8253AE48-7084-4178-A1B1-94738215463F@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/vdFurtlRy1uY5oNAxZoWo5IwSKI>
Subject: Re: [Gen-art] [rmcat] Genart last call review of draft-ietf-rmcat-nada-11
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: Sun, 25 Aug 2019 13:35:04 -0000

Thank you Xiaoqing.  The revised documents looks good to me.
Yours,
Joel

On 8/25/2019 12:33 AM, Xiaoqing Zhu (xiaoqzhu) wrote:
> Hi Joel,
> 
> Just wanted to update that we've submitted the revised draft (-12) where changes as stated below for addressing your comments.
> 
> https://tools.ietf.org/html/draft-ietf-rmcat-nada-12
> 
> Thanks again for reviewing this draft and helping to improve it.
> 
> Best,
> Xiaoqing
> 
> On 8/13/19, 10:31 AM, "rmcat on behalf of Joel M. Halpern" <rmcat-bounces@ietf.org on behalf of jmh@joelhalpern.com> wrote:
> 
>      Thank you.  Those changes will address my concerns very effectively.
>      Yours,
>      Joel
>      
>      On 8/13/2019 11:26 AM, Xiaoqing Zhu (xiaoqzhu) wrote:
>      > Dear Joel,
>      >
>      > Many thanks for your review of this draft.  Please find our responses as below, tagged [Authors].
>      >
>      > Best,
>      > Xiaoqing (on behalf of all authors)
>      >
>      > On 8/5/19, 5:17 PM, "Joel Halpern via Datatracker" <noreply@ietf.org> wrote:
>      >
>      >      Reviewer: Joel Halpern
>      >      Review result: Almost 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-nada-11
>      >      Reviewer: Joel Halpern
>      >      Review Date: 2019-08-05
>      >      IETF LC End Date: 2019-08-12
>      >      IESG Telechat date: Not scheduled for a telechat
>      >
>      >      Summary: This document is almost ready for publication as an Experimental RFC
>      >
>      >      Major issues:
>      >         It is unclear reading this RFC how the observation information is to be
>      >         communicated from the receiver to the sender.  At first I thought it was to
>      >         use the RTP Receiver report.  But there is no description of how to map the
>      >         fields to that report.   Then section 5.3 describes requirements for a
>      >         reporting mechanism, but does not seem to actually define one.   Thus, I am
>      >         left unclear how independent interoperable implementations of this draft can
>      >         be created.
>      >
>      > [Authors]  Thanks for raising this point. The feedback format is a topic covered
>      > by another currently pending draft (https://tools.ietf.org/html/draft-ietf-avtcore-cc-feedback-message-04),
>      > which indeed aims at ensuring interoperability of independent implementations of
>      > RMCAT congestion control solutions.  Therefore, in this draft we only specified what type
>      > of information is needed (e.g., receiving rate) and the unit and bit budget it is expressed
>      > in (e.g., in bps in 32 bits) in the feedback from the receiver.  We also pointed out in Sec. 6.4
>      > that an alternative way to implement this draft would be to leverage feedback messages
>      > that contain per-packet information (e.g., delay and loss info) and to move all the calculations
>      > from the receiver to the sender.
>      >
>      > [Author] Given the above considerations, we refrained from specifying a specific feedback
>      > format. However, we should perhaps add a reference pointing to the cc-feedback-message draft.
>      > Will do that in the next revision.
>      >
>      >      Minor issues:
>      >          The document has 7 front page authors.   The shepherd writeup does not
>      >          comment on this. The shepherd writeup seems quite sparse.  II would have
>      >          expected some reference to the experimental behavior described in the draft.
>      >
>      > [Authors] Thanks for raising the concern about long list of front page authors. We got some
>      > additional guidance from the AD and will make some adjustments accordingly.
>      >
>      > [Authors] As for comments on the experimental behavior: we have presented in recent IETF meetings
>      > on several sets of real-world evaluations of one implementation of NADA.  But, admittedly, the draft
>      > is lagging behind in not yet adding pointers to those results. Your suggestion is a great one and we'll add
>      > corresponding pointer (see links below) and related discussions in the next version.
>      >
>      > * https://datatracker.ietf.org/meeting/103/materials/slides-103-rmcat-nada-implementation-in-mozilla-browser-00
>      > * https://datatracker.ietf.org/meeting/105/materials/slides-105-rmcat-nada-update-02.pdf
>      >
>      >
>      >          This comment is just to confirm that I am reading the draft correctly.  It
>      >          looks like when the observed delay cross the delay boundary, the reporting
>      >          system reports using a smaller delay than actually approved (slightly more
>      >          than 1/9th of observed delay when delay is 3*QTH).  I presume this is
>      >          intentional, and that the various analysis pointed to evaluate the risks of
>      >          such false reporting?
>      >
>      > [Authors]  Yes, your understanding is correct. The main motivation for this "delay warping"
>      > In the presence of persistently high queuing delay *and* presence of loss is to help the flow to
>      > sustain a more fair rate when competing against aggressive loss-based flows.  Will follow your
>      > advice and add some discussions on the potential risks involved in performing this "delay warping".
>      >
>      >          Is it intentional in section 4.3 in the pseudo-code that the rate clipping
>      >          (to keep the rate between RMIN and RMAX) is only applied to the gradual
>      >          rate change, not to the accelerated rate change?  The later code says that
>      >          the clipping is always applied, which is what I would expect.
>      >
>      > [Authors]  Thanks to the catch. The clipping is always applied.  Will fix the text accordingly.
>      >
>      >      Nits/editorial comments:
>      >
>      >
>      > [Authors]  Thanks again for your above comments. Our next round of revision (version -12) will incorporate
>      > changes as mentioned in our above response.
>      >
>      
>      
>