[bmwg] Second part -- Re: FW: WGLC on New version of draft-ietf-bmwg-ngfw-performance

Gabor LENCSE <lencse@hit.bme.hu> Fri, 14 May 2021 16:57 UTC

Return-Path: <lencse@hit.bme.hu>
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 2E1843A38C5 for <bmwg@ietfa.amsl.com>; Fri, 14 May 2021 09:57:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-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 pJeZlpQTZK-E for <bmwg@ietfa.amsl.com>; Fri, 14 May 2021 09:57:06 -0700 (PDT)
Received: from frogstar.hit.bme.hu (frogstar.hit.bme.hu [IPv6:2001:738:2001:4020::2c]) (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 D9BAD3A38C4 for <bmwg@ietf.org>; Fri, 14 May 2021 09:57:05 -0700 (PDT)
Received: from [192.168.1.131] (host-79-121-42-155.kabelnet.hu [79.121.42.155]) (authenticated bits=0) by frogstar.hit.bme.hu (8.15.2/8.15.2) with ESMTPSA id 14EGuYl6004648 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Fri, 14 May 2021 18:56:39 +0200 (CEST) (envelope-from lencse@hit.bme.hu)
X-Authentication-Warning: frogstar.hit.bme.hu: Host host-79-121-42-155.kabelnet.hu [79.121.42.155] claimed to be [192.168.1.131]
To: "MORTON JR., AL" <acmorton@att.com>, "bmonkman@netsecopen.org" <bmonkman@netsecopen.org>
Cc: 'Bala Balarajah' <bala@netsecopen.org>, 'Bala Balarajah' <bm.balarajah@gmail.com>, "bmwg@ietf.org" <bmwg@ietf.org>, "'MORTON, ALFRED C (AL)'" <acm@research.att.com>, 'Sarah Banks' <sbanks@encrypted.net>, Gábor LENCSE <lencse@hit.bme.hu>
References: <413e779fd7eb4dd4b3aa8473c171e282@att.com> <f1a2b5c5-ebf2-12ab-b053-b9b2538342ad@hit.bme.hu> <047501d745bb$e22f4ab0$a68de010$@netsecopen.org> <7dc6b282-7f41-bf7c-f09c-65e7ce94b674@hit.bme.hu> <048801d745be$31424b50$93c6e1f0$@netsecopen.org> <84196d5ce7474f9196ab000be64c49fd@att.com>
From: Gabor LENCSE <lencse@hit.bme.hu>
Message-ID: <c9a5ff54-29db-bcc0-2c50-8f2287f99b3a@hit.bme.hu>
Date: Fri, 14 May 2021 18:56:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <84196d5ce7474f9196ab000be64c49fd@att.com>
Content-Type: multipart/alternative; boundary="------------1FE9F7365DDE2C445618CAA5"
Content-Language: en-US
X-Virus-Scanned: clamav-milter 0.102.4 at frogstar.hit.bme.hu
X-Virus-Status: Clean
Received-SPF: pass (frogstar.hit.bme.hu: authenticated connection) receiver=frogstar.hit.bme.hu; client-ip=79.121.42.155; helo=[192.168.1.131]; envelope-from=lencse@hit.bme.hu; x-software=spfmilter 2.001 http://www.acme.com/software/spfmilter/ with libspf2-1.2.10;
X-DCC--Metrics: frogstar.hit.bme.hu; whitelist
X-Scanned-By: MIMEDefang 2.79 on 152.66.248.44
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/clwiQioeLSYznxNMauuiYSuAKtQ>
Subject: [bmwg] Second part -- Re: FW: WGLC on New version of draft-ietf-bmwg-ngfw-performance
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: Fri, 14 May 2021 16:57:09 -0000

Dear Al, Authors and BMWG Members,

Al, thank you very much for extending the deadline. However, today I 
managed to finish the review of the draft.

I think this draft is matured enough. I could find only minor formal 
issues in the text about the benchmarking procedures. (Although I kept 
the categories of Discuss/Bugs/Nits, I did not find any significant new 
issue. My entries in the "Discuss" category are either reiterations from 
my previous review, or rather editorial ones.)

Discuss:
--------

page 25
7.1.4.2.

    [...] The test equipment SHOULD start to measure and record
    all specified KPIs and the frequency of measurements SHOULD be less
    than 2 seconds.

What does the "frequency of measurements" mean?
I would expect that the KPIs are mausered continously.
Perhaps it is the "frequency of results produced", that is, the "time 
window for collecting the results and calculating their average" should 
be less than 2 seconds?

------------------

page 26

    The client SHOULD negotiate HTTP 1.1 and close the connection with
    FIN immediately after completion of one transaction.  In each test
    iteration, client MUST send GET command requesting a fixed HTTP
    response object size.

As I mentioned before (I mean: in my previous review), I recommend the 
inclusion of HTTP/2.

------------------

page 27

    c.  During the sustain phase, traffic should be forwarded at a
        constant rate.

- How is "constant rate" defined?
   E.g. the maximum deviation SHOULD be less than 10%, as required at "d."?
- Why "should" is not capitalized here?

------------------

page 28

    The test equipment SHOULD start to measure and record all specified
    KPIs and the frequency of measurements SHOULD be less than 2 seconds.
    Continue the test until all traffic profile phases are completed.

The same comment, as for the "frequency of measurements" on page 25.

------------------

page 30

    b.  Traffic should be forwarded constantly.

The same comments as regarding the "constant rate" on page 27.
 From now on, I will not report it again...

------------------

pages 28-32

Unlike in other cases, HTTP version was not mentioned at all in Section 7.3.
However, I think it is as important here, as in other cases.

------------------

page 31

    [...] The test
    equipment SHOULD start to measure and record all specified KPIs and
    the frequency of measurements SHOULD be less than 2 seconds.

The same comment, as for the "frequency of measurements" on page 25.

 From now on, I will not report it again...

------------------

page 32

    For consistency both the single and multiple transaction test MUST be
    configured with HTTP 1.1.

As I mentioned before, I recommend the inclusion of HTTP/2.
HTTP 1.1 is mentioned again it the next two paragraphs and later many 
times. I will not report it again...


------------------------------------------------------


Bugs:
-----

page 30

                           Table 4: Mixed Objects

There is a "Table 4" on page 11.
(Should be renumbered. Please take care for their citations in the text, 
too!)

------------------

page 31

    The measured KPIs during the sustain phase MUST meet the test results
    validation criteria "a" defined in Section 7.3.3.3.

Why only "a" counts?
There are "b" and "c" too.

------------------

page 34

    results validation criteria a, b, c, d, e and f defined in
    Section 7.4.3.3.

Criterion "f" is undefined, as the last one is "e".

------------------

page 37

    During the sustain phase, the DUT/SUT SHOULD reach the "Initial
    concurrent TCP connections".  The measured KPIs during the sustain
    phase MUST meet the test results validation criteria "a" and "b"
    defined in Section 7.5.3.3.


Why only "a" and "b" counts?
There is "c" too.

------------------

page 44

    The measured KPIs during the sustain phase MUST meet the test results
    validation criteria "a" defined in Section 7.7.3.3.

Why only "a" counts?
There are "b" and "c" too.

------------------

page 47

    results validation criteria a, b, c, d, e and f defined in
    Section 7.8.3.3.

Criterion "f" is undefined, as the last one is "e".

------------------

page 50

    During the sustain phase, the DUT/SUT SHOULD reach the "Initial
    concurrent TCP connections".  The measured KPIs during the sustain
    phase MUST meet the test results validation criteria "a" and "b"
    defined in Section 7.9.3.3.

Why only "a" and "b" counts?
There is "c" too.


------------------------------------------------------


Nits:
-----

page 27

    "initial connections per second" as defined in the parameters
-->
    "Initial connections per second" as defined in the parameters

------------------

page 41


    iteration can be interrupted and the result for 64 KByte SHOULD NOT
    be reported).
-->
    iteration MAY be interrupted and the result for 64 KByte SHOULD NOT
    be reported).

(It is so in Section 7.2.4.2, thus it would be consistent to do so here, 
too)

------------------

Page 43:

Table 5 seems to have the same content as Table 4.
If it is so, it is worth including it twice?

------------------

page 44

    "initial inspected throughput" as defined in the parameters
-->
    "Initial inspected throughput" as defined in the parameters

------------------

page 53

    mode and all detected attack traffic MUST be dropped and the session
    Should be reset
-->
    mode and all detected attack traffic MUST be dropped and the session
    SHOULD be reset.

(perhaps)

------------------

    This document attempts to classify the DUT/SUT in four different four
    different categories based on its maximum supported firewall
-->
    This document attempts to classify the DUT/SUT in four different
    categories based on its maximum supported firewall

("four different" was repeated)

------------------

page 56

    Extra Small (XS) - supported throughput less than 1Gbit/s

    Small (S) - supported throughput less than 5Gbit/s

    Medium (M) - supported throughput greater than 5Gbit/s and less than
    10Gbit/s

    Large (L) - supported throughput greater than 10Gbit/s

Mathematicians could ask: and what if the supported throughput is 
exactly 10Gbit/s? ;-)

That's all.

Best regards,

Gábor


On 5/10/2021 7:34 PM, MORTON JR., AL wrote:
>
> of course Brian and Gábor, I can use the extra time myself.
>
> BMWG,
>
> We will extend the deadline for WGLC to May 21, as requested.
>
> Al
>
> bmwgco-chair
>
>