Re: [bmwg] Martin Duke's No Objection on draft-ietf-bmwg-ngfw-performance-13: (with COMMENT)

Carsten Rossenhoevel <cross@eantc.de> Thu, 03 February 2022 01:03 UTC

Return-Path: <cross@eantc.de>
X-Original-To: bmwg@ietfa.amsl.com
Delivered-To: bmwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F6763A109F; Wed, 2 Feb 2022 17:03:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.613
X-Spam-Level:
X-Spam-Status: No, score=-2.613 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 vHokim6Ifz5A; Wed, 2 Feb 2022 17:03:54 -0800 (PST)
Received: from obelix.eantc.de (ns.eantc.com [89.27.172.100]) (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 47A0F3A1097; Wed, 2 Feb 2022 17:03:54 -0800 (PST)
Received: from [172.31.5.6] by obelix.eantc.de with esmtp (Exim 4.89) (envelope-from <cross@eantc.de>) id 1nFQXO-0004JC-0I; Thu, 03 Feb 2022 02:03:50 +0100
Message-ID: <a59b8db2-89e6-624d-36ab-4ec86f97bf8c@eantc.de>
Date: Thu, 03 Feb 2022 02:03:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0
To: Martin Duke <martin.h.duke@gmail.com>, The IESG <iesg@ietf.org>
Cc: draft-ietf-bmwg-ngfw-performance@ietf.org, bmwg-chairs@ietf.org, bmwg@ietf.org, Al Morton <acm@research.att.com>
References: <164374530296.19133.7805387937993224026@ietfa.amsl.com>
From: Carsten Rossenhoevel <cross@eantc.de>
Organization: EANTC AG
In-Reply-To: <164374530296.19133.7805387937993224026@ietfa.amsl.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/-YVH9ds5qzDQLd94l2rbtgfGK14>
Subject: Re: [bmwg] Martin Duke's No Objection on draft-ietf-bmwg-ngfw-performance-13: (with COMMENT)
X-BeenThere: bmwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Benchmarking Methodology Working Group <bmwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bmwg>, <mailto:bmwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bmwg/>
List-Post: <mailto:bmwg@ietf.org>
List-Help: <mailto:bmwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bmwg>, <mailto:bmwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 03 Feb 2022 01:04:00 -0000

Martin,

Here is a response to your second comment.  The authors have discussed 
the Delayed ACK statement once more.  In general, it would be possible 
to specify the limit in time in addition.  A typical value would be 200 
ms (Windows OS default).  However, it is unclear to us if such a limit 
would cover any corner cases and whether it would generally reduce 
confusion instead of increasing it (problems with inclusive vs. 
exclusive "or" in normative statements).

If you would still like us to add a delayed ack limit in time, could you 
please suggest specific text that - given your experience with IETF 
documents - would be consistent and represent the normative statements 
correctly?

Apologies, it is not my plan to delegate our work to you :), but we are 
really unsure how to formulate this precisely.

Thank you, Carsten


Am 2/1/2022 um 8:55 PM schrieb Martin Duke via Datatracker:
> Martin Duke has entered the following ballot position for
> draft-ietf-bmwg-ngfw-performance-13: 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/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-bmwg-ngfw-performance/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> (4.3.1.3) RFC8446 is not the reference for HTTP/2.
>
> (4.3.1.1), (4.3.2.1) Is there a reason that delayed ack limits are defined only
> in terms of number of bytes, instead of time? What if an HTTP request (for
> example) ends, and the delayed ack is very long? Note also that the
> specification for delayed acks limits it to every two packets, although in the
> real world many endpoints use much higher thresholds. [It's OK to keep it at
> 10*MSS if you prefer].
>
> (4.3.3.1) What is a "TCP persistence stack"?
>
>
>
-- 
Carsten Rossenhövel
Managing Director, EANTC AG (European Advanced Networking Test Center)
Salzufer 14, 10587 Berlin, Germany
office +49.30.3180595-21, fax +49.30.3180595-10, mobile +49.177.2505721
cross@eantc.de, https://www.eantc.de

Place of Business/Sitz der Gesellschaft: Berlin, Germany
Chairman/Vorsitzender des Aufsichtsrats: Herbert Almus
Managing Directors/Vorstand: Carsten Rossenhövel, Gabriele Schrenk
Registered: HRB 73694, Amtsgericht Charlottenburg, Berlin, Germany
EU VAT No: DE812824025