[rmcat] Benjamin Kaduk's No Objection on draft-ietf-rmcat-nada-12: (with COMMENT)
Benjamin Kaduk via Datatracker <noreply@ietf.org> Thu, 05 September 2019 17:23 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: rmcat@ietf.org
Delivered-To: rmcat@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id C7EF51209C1; Thu, 5 Sep 2019 10:23:20 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Benjamin Kaduk via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-rmcat-nada@ietf.org, Martin Stiemerling <mls.ietf@gmail.com>, rmcat-chairs@ietf.org, mls.ietf@gmail.com, rmcat@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.100.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Benjamin Kaduk <kaduk@mit.edu>
Message-ID: <156770420074.22682.347461921212910371.idtracker@ietfa.amsl.com>
Date: Thu, 05 Sep 2019 10:23:20 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/rmcat/yZh62LLgZJhzEkIOGnFFQWQib5k>
Subject: [rmcat] Benjamin Kaduk's No Objection on draft-ietf-rmcat-nada-12: (with COMMENT)
X-BeenThere: rmcat@ietf.org
X-Mailman-Version: 2.1.29
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 Sep 2019 17:23:21 -0000
Benjamin Kaduk has entered the following ballot position for draft-ietf-rmcat-nada-12: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-rmcat-nada/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for this document; it provides a clear picture of an interesting scheme, and it will be interesting to see further reports of its efficacy. I just have some essentially editorial comments, that may not even be worth responding to, so I will try to sneak them in after the telechat. Do we need to say anything further about aborting the flow when the level of congestion does not support even the minimum bitrate supported by the encoder? Mirja thinks this is sufficiently well-known that we probably don't need to, which seems reasonable to me. Section 4 o Accelerated ramp-up: when the bottleneck is deemed to be underutilized, the rate increases multiplicatively with respect to the rate of previously successful transmissions. The rate "multiplicatively" is synonymous with "exponentially" here? (Thank you for specifying it this way, though, to make clear what the multiplier value is.) Section 4.3 QBOUND gamma = min(GAMMA_MAX, ------------------) (3) rtt+DELTA+DFILT It seems impossible for the minimum to be GAMMA_MAX with the defaults for QBOUND, DELTA, and DFILT, since the second argument to min() is less than 50/(120+100) = 0.23, which is much less than the default GAMMA_MAX of 0.5. Section 5.1.1 one-way delay and base delay. By re-estimating the base delay periodically, one can avoid the potential issue of base delay expiration, whereby an earlier measured base delay value is no longer valid due to underlying route changes. All delay estimations are I think that clock *rate* skew between peers could also cause issues with base delay values growing less useful over time. Clock rate skew is much less prominent than absolute clock skew, though. based on sender timestamps with a recommended granularity of 100 microseconds or higher. Is this a normative requirement? Also, pedantically, I think "granularity of 100 microseconds or higher" has "higher" apply to the numerical value 100, so it would include a granularity of 1 second. I see that later on we recommend measuring the delay as an integer multiple of 100 microseconds, so this seems like the intended sense, but does the scheme become less useful if the granularity of the measurment becomes too coarse-grained (e.g., the second granularity I mentioned above)? If so, we may want to put a bound on the other direction as well. Section 5.3 o Aggregated congestion signal (x_curr): the most recently updated value, calculated by the receiver according to Section 4.2. This information is expressed with a unit of 100 microsecond (i.e., 1/10 of a millisecond) in 15 bits. This allows a maximum value of x_curr at approximately 3.27 second. There's perhaps a minor editorial mismatch between the "information is required" intro and declarative "is expressed in [specific format]". (Similarly for r_recv.)
- [rmcat] Benjamin Kaduk's No Objection on draft-ie… Benjamin Kaduk via Datatracker
- Re: [rmcat] Benjamin Kaduk's No Objection on draf… Xiaoqing Zhu (xiaoqzhu)