Re: [bmwg] Genart telechat review of draft-ietf-bmwg-ngfw-performance-13

Carsten Rossenhoevel <cross@eantc.de> Wed, 02 February 2022 08:10 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 BA4EF3A2873; Wed, 2 Feb 2022 00:10:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.612
X-Spam-Level:
X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 j5_rSiC-ItuE; Wed, 2 Feb 2022 00:10:37 -0800 (PST)
Received: from obelix.eantc.de (mailgw.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 5E04B3A2879; Wed, 2 Feb 2022 00:10:36 -0800 (PST)
Received: from [172.31.5.6] by obelix.eantc.de with esmtp (Exim 4.89) (envelope-from <cross@eantc.de>) id 1nFAim-0000MI-7L; Wed, 02 Feb 2022 09:10:32 +0100
Content-Type: multipart/alternative; boundary="------------XHNcwMfpF4tzo1IATGQisZjv"
Message-ID: <1ea89017-e833-7240-c6a3-9d08d68603ff@eantc.de>
Date: Wed, 02 Feb 2022 09:10:32 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1
To: Matt Joras <matt.joras@gmail.com>
Cc: gen-art@ietf.org, bmwg@ietf.org, draft-ietf-bmwg-ngfw-performance.all@ietf.org, last-call@ietf.org
References: <164373365337.23647.13599772226951368639@ietfa.amsl.com> <ddf11891-8034-f28f-32d6-648ea2bf917f@eantc.de> <CADdTf+hwZefRf9A3rEx94rH_bReKcgMoGMySCWN_dvn08_9-Dg@mail.gmail.com>
From: Carsten Rossenhoevel <cross@eantc.de>
In-Reply-To: <CADdTf+hwZefRf9A3rEx94rH_bReKcgMoGMySCWN_dvn08_9-Dg@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/r6tFif4o1gzMjf-8HRnq0Yrjh5k>
Subject: Re: [bmwg] Genart telechat review of draft-ietf-bmwg-ngfw-performance-13
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 08:10:45 -0000

Hi Matt, Toerless,

Thank you both for your guidance.  We will proceed as suggested.

Best regards, Carsten


Am 02.02.2022 um 08:32 schrieb Matt Joras:
> Hi Carsten,
>
> I don't have a good answer unfortunately. In my opinion the mentions 
> of QUIC and HTTP/3 don't add a lot, and feel a bit bolted on so to 
> speak. This is of course understandable given the relatively recent 
> standardization of QUIC itself and the lack of testing experience with 
> it and the numerous implementations.
>
> If it were me I would perhaps instead make a note of QUIC as a 
> potential transport protocol for HTTP, and acknowledge that the 
> document will not attempt to enumerate specific testing procedures for 
> it. The current text probably would not lead to useful results for 
> QUIC performance testing relative to TCP.
>
> That's my two cents anyway.
>
> Matt Joras
>
> On Tue, Feb 1, 2022, 11:14 PM Carsten Rossenhoevel <cross@eantc.de> wrote:
>
>     Dear Matt,
>
>     Thank you for your review!
>
>     We added QUIC to the draft during one of the BMWG sessions based on
>     suggestions from the attendees.  The authors are a bit unsure how
>     to fix
>     the draft that's up for approval so that it would be precise and
>     fully
>     compliant with QUIC environments.
>
>     Do you have any specific suggestions how to correct the text, keeping
>     QUIC in scope?
>
>     Alternatively, we could remove QUIC references and take it out of
>     scope
>     and cover it in a future amendment.  Not the best solution, but after
>     more than three years of drafting with so many contributors, we would
>     like to avoid opening a new discussion area that would likely
>     delay the
>     work by another year.
>
>     Best regards, Carsten
>
>
>     Am 2/1/2022 um 5:40 PM schrieb Matt Joras via Datatracker:
>     > Reviewer: Matt Joras
>     > 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 wait for direction from your
>     > document shepherd or AD before posting a new version of the draft.
>     >
>     > For more information, please see the FAQ at
>     >
>     > <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>     >
>     > Document: draft-ietf-bmwg-ngfw-performance-13
>     > Reviewer: Matt Joras
>     > Review Date: 2022-01-31
>     > IETF LC End Date: 2021-12-29
>     > IESG Telechat date: 2022-02-03
>     >
>     > Nits/editorial comments:
>     >
>     > Section 4.3.1.1
>     > This section details TCP stack attributes in great detail. However,
>     > subsequently HTTP/3 and QUIC are both mentioned in 4.3.1.3..
>     QUIC is in need of
>     > tuning just as much as TCP, if not more.
>     >
>     > " HTTP/3 emulated browser uses QUIC ([RFC9000]) as transport
>     protocol." should
>     > be reworded, and I'm not exactly sure what it is trying to convey.
>     >
>     > "Depending on test scenarios and selected HTTP version, HTTP
>     header compression
>     > MAY be set to enable or disable." should probably read " be
>     enabled or
>     > disabled."
>     >
>     > Similarly in sections 7, there is a lot of specific mention of
>     TCP connections,
>     > TCP RSTs, FINs, etc. and continued mentioning of HTTP. Since
>     QUIC is a
>     > significant carrier of HTTP traffic it seems these sections
>     should not be so
>     > specific to TCP. Especially since it seems as though for these
>     kinds of devices
>     > their limits may very well be different for UDP or TCP flows.
>     >
>     >
>     -- 
>     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
>