Subject: [Last-Call] Genart telechat review of draft-ietf-bmwg-ngfw-performance-13

From: Matt Joras via Datatracker <[email-masked]>
Date: Tue, 01 Feb 2022 08:40:53 -0800

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.

---

From: Carsten Rossenhoevel <[email-masked]>
Date: Wed, 2 Feb 2022 08:14:50 +0100

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

-- 
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
[email-masked], 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

---

From: Matt Joras <[email-masked]>
Date: Tue, 1 Feb 2022 23:32:29 -0800

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

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 2 Feb 2022 08:38:49 +0100

IMHO:

Just write down the current status of QUIC: Support and understanding of QUIC
in next-gen security devices is in its infancy, and so are details about the
test procedures in this document. Nevertheless, it is important enough that
it should not be ignored and is included as good as possible in the document.

Cheers
    Toerless

On Wed, Feb 02, 2022 at 08:14:50AM +0100, Carsten Rossenhoevel wrote:
> 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
> 
> 
> last-call mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/last-call

-- 
---
[email-masked]

---

From: Carsten Rossenhoevel <[email-masked]>
Date: Wed, 2 Feb 2022 09:10:32 +0100

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.
>

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 2 Feb 2022 09:20:33 +0100

> probably would not lead to useful results for QUIC performance testing

I would very much hope that a new protocol like QUIC would NOT require the same
amount of nerd-knob tuning as potentially decade old TCP stacks.  The need
to tune parameters in TCP for different situations has been one of the core
operational pain points.

Besides: this document does not attempt to test the variety of "challenged path"
situations, which should it make it even more benighn to test with just defaults.
(and those challenged path performance measurements are better done in a 
 non-security-device specific BMWG document).

If anything, the main security relevant TCP/QUIC comparison that i would like
to see in future IETF work is a comparison to the extend that the same security
device can perform the same degree of inspection for TCP vs QUIC flows.
Given how QUIC further enhances end-to-end privacy and hides transport level parameters,
i would imagine that the security device on average can do less. But i have not seen good
quantitative or even qualitative comparisons (some of this already applied to
TCP with TLS-1.3).

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Lars Eggert <[email-masked]>
Date: Thu, 3 Feb 2022 15:40:51 +0200

Matt, thank you for your review. I have entered a Discuss ballot for this document based on my own review.

Lars

> On 2022-2-1, at 18:40, Matt Joras via Datatracker <[email-masked]> wrote:
> 
> Reviewer: Matt Joras