[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 > >
- [bmwg] FW: WGLC on New version of draft-ietf-bmwg… MORTON JR., AL
- Re: [bmwg] FW: WGLC on New version of draft-ietf-… Gabor LENCSE
- Re: [bmwg] FW: WGLC on New version of draft-ietf-… bmonkman
- Re: [bmwg] FW: WGLC on New version of draft-ietf-… Gabor LENCSE
- Re: [bmwg] FW: WGLC on New version of draft-ietf-… bmonkman
- Re: [bmwg] FW: WGLC on New version of draft-ietf-… MORTON JR., AL
- [bmwg] Second part -- Re: FW: WGLC on New version… Gabor LENCSE
- Re: [bmwg] Second part -- Re: FW: WGLC on New ver… bmonkman
- [bmwg] Sequential vs. random -- Re: FW: WGLC on N… Gábor LENCSE
- Re: [bmwg] FW: WGLC on New version of draft-ietf-… MORTON JR., AL
- Re: [bmwg] FW: WGLC on New version of draft-ietf-… bmonkman
- Re: [bmwg] Sequential vs. random -- Re: FW: WGLC … bmonkman
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… Sarah Banks
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… bmonkman
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… bmonkman
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… bmonkman
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… bmonkman
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… Sarah Banks
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… Sarah Banks
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… bmonkman
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… MORTON JR., AL
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… bmonkman
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… Carsten Rossenhoevel
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… MORTON JR., AL
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… Sarah Banks
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… bmonkman
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… Carsten Rossenhoevel
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… Sarah Banks
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… bmonkman
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… MORTON JR., AL
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… bmonkman
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… Gábor LENCSE
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… Carsten Rossenhoevel
- Re: [bmwg] WGLC on New version of draft-ietf-bmwg… Gábor LENCSE