Re: [bmwg] Martin Duke's No Objection on draft-ietf-bmwg-ngfw-performance-13: (with COMMENT)
Carsten Rossenhoevel <cross@eantc.de> Wed, 02 February 2022 07:06 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 DE2DD3A266A; Tue, 1 Feb 2022 23:06:39 -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 u4-mB8jTuUpA; Tue, 1 Feb 2022 23:06:35 -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 4B8073A2669; Tue, 1 Feb 2022 23:06:32 -0800 (PST)
Received: from [172.31.5.6] by obelix.eantc.de with esmtp (Exim 4.89) (envelope-from <cross@eantc.de>) id 1nF9im-0008V8-2d; Wed, 02 Feb 2022 08:06:28 +0100
Message-ID: <a2b604a1-90e9-5692-e869-ff32498807fc@eantc.de>
Date: Wed, 02 Feb 2022 08:06:27 +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/vllJuAVz9z8wVoZHhDFn5WNCHzI>
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: Wed, 02 Feb 2022 07:06:40 -0000
Dear Martin, Thank you very much for your review. Re 4.3.1.3: The reference is a mistake indeed. Amazing that nobody spotted it before :-( We will fix it to be RFC 7540. Re 4.3.3.1: TCP persistence allows to send multiple HTTP requests using a single TCP connection. We got used to this term during the drafting sessions; but I think a more precise and more frequently used term in the industry is "HTTP persistence". Does it improve the text from your point of view if we rename "TCP persistence stack" to "HTTP persistent connections"? (https://en.wikipedia.org/wiki/HTTP_persistent_connection) Re 4.3.1.1, 4.3.2.1: Your question regarding delayed ack requires more analysis with contributors. Please bear with us. I hope to have a coordinated response for you later today. Best regards, 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
- [bmwg] Martin Duke's No Objection on draft-ietf-b… Martin Duke via Datatracker
- Re: [bmwg] Martin Duke's No Objection on draft-ie… Carsten Rossenhoevel
- Re: [bmwg] Martin Duke's No Objection on draft-ie… Martin Duke
- Re: [bmwg] Martin Duke's No Objection on draft-ie… Carsten Rossenhoevel
- Re: [bmwg] Martin Duke's No Objection on draft-ie… bmonkman
- Re: [bmwg] Martin Duke's No Objection on draft-ie… Martin Duke