Re: [bmwg] WG Last Call: draft-ietf-bmwg-ngfw-performance-05
bmonkman@netsecopen.org Thu, 24 December 2020 16:02 UTC
Return-Path: <bmonkman@netsecopen.org>
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 4E3A23A12D7 for <bmwg@ietfa.amsl.com>; Thu, 24 Dec 2020 08:02:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=netsecopen-org.20150623.gappssmtp.com
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 r2IivRKdrHSN for <bmwg@ietfa.amsl.com>; Thu, 24 Dec 2020 08:02:52 -0800 (PST)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298383A12C6 for <bmwg@ietf.org>; Thu, 24 Dec 2020 08:02:52 -0800 (PST)
Received: by mail-qk1-x731.google.com with SMTP id 22so2345914qkf.9 for <bmwg@ietf.org>; Thu, 24 Dec 2020 08:02:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=netsecopen-org.20150623.gappssmtp.com; s=20150623; h=from:to:cc:references:in-reply-to:subject:date:message-id :mime-version:content-transfer-encoding:thread-index :content-language; bh=b/vANnBf/AhmiQ7VxyYheU/w3LXPBSoeU+lsA0Gjzhw=; b=kzSydFoaEEwzG+5GEsFolxnweWQyHyj9hZVaveyrbMhzOBqbn/zoa+zTQRnA+bU5tg Vsn/BFH5XZYmX7fOP35y67pYc04GMFH8+7R09ERsS8f5I5UK0RoZl+IB5p6Kzy/cjksk 8YyTi9lkfiDaaRh5k4SoOeRdt3bYJORnkuHlpouefTkyE3cGvqxeH9zDVJpu60dsgfJl qrlCgZy1Fqjv0H6H5qXMN2yI0FIyz9O9D5wPLn9J45Ewv1jLER2vzPJDSMSiZLgYpiot EKWg8h15oOs39CXDaPCfTyv7YSoM96MPrI+gcwPgbLVngRHuRlzL6CvzSZxRTWRUYC8y 7BJw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-transfer-encoding:thread-index :content-language; bh=b/vANnBf/AhmiQ7VxyYheU/w3LXPBSoeU+lsA0Gjzhw=; b=toXdUVBoM9Py4D0VvT7rsuComaHi9RKsiyC9fHHVWpsMZKJnr7P7C9jGeOovWvyjXQ mXakl6TVYE8Eebz79kpH9V+4SE3pl16fUEJKXrwv4yl1WKdKCBhtNopaesGyEFUMgtez Ra91dhuugW2bNFytXRY3uOKVXtfRcMMvVcgLx4EHWzwEZFzsEC2dFUTmQRaWK/bMeUFx GkE8W4o0I1j2iwXGx5yVykDqNiWYci/i3U3VQbeJOSNWlxrccbMWgURtNFJ4lBECEuMx TrCGDx3G69B7EEFgWtdT9d1n5CdTGaKVZX942DysgwI9rXOVJKQa7MpCtULmYBbWFGGA hCyg==
X-Gm-Message-State: AOAM531l42tgfMkhrvWHgLmd2K+c4WBtrkmNx5ZRWLWgRbZc6CGJYE+N nYx04KxSmql0ch/pzAs22NxSkg==
X-Google-Smtp-Source: ABdhPJwb5kvf+m1ASiXrx0W6ecWS5JaeHOrXsc27BG/nCh0AKLN73GeWhgNgFw+P4pL6SjQukZQOwA==
X-Received: by 2002:a05:620a:1317:: with SMTP id o23mr15681236qkj.336.1608825771316; Thu, 24 Dec 2020 08:02:51 -0800 (PST)
Received: from WINDOWSU6SOVGL (c-98-235-212-118.hsd1.pa.comcast.net. [98.235.212.118]) by smtp.gmail.com with ESMTPSA id a5sm17761729qtn.57.2020.12.24.08.02.49 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 24 Dec 2020 08:02:50 -0800 (PST)
From: bmonkman@netsecopen.org
To: "'Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco)'" <vrpolak=40cisco.com@dmarc.ietf.org>, bmwg@ietf.org
Cc: "'MORTON, ALFRED C (AL)'" <acm@research.att.com>, 'Bala Balarajah' <bala@netsecopen.org>, 'Carsten Rossenhoevel' <cross@eantc.de>
References: <4D7F4AD313D3FC43A053B309F97543CF014767877B@njmtexg5.research.att.com> <BY5PR11MB4038A9A8D3A833F8AA2B03A7BDDE0@BY5PR11MB4038.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB4038A9A8D3A833F8AA2B03A7BDDE0@BY5PR11MB4038.namprd11.prod.outlook.com>
Date: Thu, 24 Dec 2020 11:02:48 -0500
Message-ID: <027801d6da0e$3ac20740$b04615c0$@netsecopen.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQEuqiYZGMRTjsr9V6cISPU4hr9IhQFfZTXVq0vJz+A=
Content-Language: en-ca
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/vNmpjcPiI2e7gURUBqd6gpVDR1Y>
Subject: Re: [bmwg] WG Last Call: draft-ietf-bmwg-ngfw-performance-05
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: Thu, 24 Dec 2020 16:02:54 -0000
Vratko et al, See comments from the authors inline below - preceded by [authors]. Brian -----Original Message----- From: bmwg <bmwg-bounces@ietf.org> On Behalf Of Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco) Sent: December 23, 2020 10:31 AM To: bmwg@ietf.org Cc: MORTON, ALFRED C (AL) <acm@research.att.com> Subject: Re: [bmwg] WG Last Call: draft-ietf-bmwg-ngfw-performance-05 > Please read and express your opinion on whether or not this > Internet-Draft should be forwarded to the Area Directors for > publication as an Informational RFC. The current draft is a large document, and I will have multiple comments. I expect some of them will be addressed by creating -06 version, so my opinion is -05 should not be forwarded for publication. > Send your comments to this list or to co-chairs at > bmwg-chairs@ietf.com The issue is, I do not have all the comments ready yet. In general, I need to spend some effort when turning my nebulous ideas into coherent sentences (mostly because only when writing the sentences I realize the topic is even more complicated than I thought at first). Also, specifically for BMWG, I want my comments to be more complete than usual. Not just "I do not like/understand this sentence", but give a new sentence and a short explanation why the new sentence is better. I have two reasons for aiming for high quality comments. First, I imagine many people are reading this list. That means, if I write a lazy superficial comment, I save my time, but readers will spend more time trying to reconstruct my meaning. (Similar to how in software development, code is written once but read many times.) Second reason is high latency on this mailing list. Usually, by the time the author reacts to the comments, the reviewer has switched their attention to other tasks, so it is better when the first comment does not need any subsequent clarifications from the reviewer. > allow for holidays and other competing topics I reserved some time before holidays, originally for improving MLRsearch, but NGFW is closer to publishing so it takes precedence. My plan is to start with giving a few low-quality comments, mainly to hint what areas I want to see improved. After holidays, I will write higher quality comments, one e-mail per area. This e-mail contains the low-quality comments (in decreasing order of brevity). 1. Test Bed Considerations. Useful, but maybe should be expanded into a separate draft. (Mainly expanding on "testbed reference pre-tests", and what to do if they fail but we still want some results.) [authors] The section "Test Bed Considerations" just gives a recommendation (even though we haven't use Capital letter "RECOMMEND"). The section describes the importance of the pre-test, and it also gives an idea about pre-test. The Test labs or any user can decide themselves, if the pre-test is needed for their test. However, based on our discussions with test labs, they usually perform such a pre-test. In our opinion, we should keep this section in the draft. It just creates an awareness of pre-test to the readers. 2. Sentence with "safety margin of 10%". Unclear. If you want to add or subtract, name both the quantity before and after the operation, so in later references it is clear which quantity is referenced. Also, why 10% and not something else (e.g. 5%)? [authors] You are right. Either we need to change the wording or remove the whole sentence. We suggest removing it 3. Is it "test bed" or "testbed"? I assume it means "SUT" plus "test equipment" together, but is should be clarified. [authors] Based on Oxford and Cambridge, it should be "test bed". We will solve the inconsistency issue in the next version. A test bed should also include test equipment. we will describe this in the next version. 4. Sustain phase follows after ramp-up phase immediately, without any pause, right? Then there is in-flight traffic at sustain phase start and end, making it hard to get precise counters. [authors] We don't think we can add a pause between ramp-up and sustain phase. Since the frequency of the measurements are 2 second and the total sustain phase is 300s,I don't think the in-flight traffic will impact accuracy of the results. However, we have two suggestions here: 1. ask test tool vendors if there is any way to add pause between two phases 2. we can describe in the draft that the measurement should occur between X sec (e.g. 2sec) after ramp-up begins and X sec before ramp-up ends. If it doesn't appear to be [possible to build in a pause we would go with option 2. 5. Validation criteria. The draft contains terms "target throughput" and "initial throughput", but also phrases like "the maximum and average achievable throughput within the validation criteria". I am not even sure if validation criteria apply to a trial (e.g. telemetry suggests test equipment behavior was not stable enough) or a whole search (e.g. maximum achievable throughput is below acceptance threshold). [authors] Section 6 .1 describes the average throughput. Due to the behavior of stateful traffic (TCP) and also test tools behavior, getting a 100% linear (stable) throughput is not easy. There will always be continuous minor spikes. That's Why we chose to measure the average values. We will remove the wording "maximum ..." in the next version. Also, we will clarify that throughput means always avg. throughput. For an e.g. "target throughput" means "average target throughput" 6. It seems the same word "throughput" is used to mean different quantities depending on context. Close examination suggests it probably means forwarding rate [0] except the offered load [1] is not given explicitly (and maybe is not even constant). When I see "throughput" I think [2] (max offered load with no loss), which does not work as generally the draft allows some loss. Also, some terms (e.g. "http throughput") do not refer to packets, but other "transactions". [authors] The throughput measurement defined in [2] doesn't fit for L7 stateful traffic. For example TCP retransmissions are not always packet loss. Due to the test complexity and test tools behavior we have to allow some transaction failures. Therefore, we needed to define a different definition for the KPI throughput. Section 6.1 describes that the KPI measures the average Layer 2 throughput. But you are right; the term "http throughput" can be considered as L7 throughput or Goodput. We will work on this in the next draft. 7. SUT state affecting performance. The draft does not mention any, so I think it assumes "stateless" SUT. An example of "stateful" SUT is NAT, where opening sessions has smaller performance than forwarding on already opened sessions. Or maybe it is assumed any such state enters a stationary state during ramp-up, so in sustain phase the performance is stable (e.g. NAT sessions may be timing out, but in a stable rate). [authors] SUT MUST be stateful, and it must do Stateful inspection. It doesn't mean that the SUT must do NAT if it is in stateful mode. NAT is just another feature which can or can't be enabled and this is based on the customer scenario. The traffic profile has limited (e.g. 10 for throughput test) transactions per TCP connection and the session will be closed once the transactions are completed. SUT will then remove the session entries from its session table. This means, there will be always new stateful sessions will be opened and established during the sustain period as well. Apart from this, we can consider whether we want to add NAT as an option feature in the feature table (table 2). 8. Stateless or stateful traffic generation. Here stateless means predetermined packets are sent at predetermined times. Stateful means time or content of next-to-send packet depends on time or content of previously received packets. Draft section 7.1 looks like stateless traffic to me (think IMIX [3]), while others look like stateful (you cannot count http transaction rate from lossy stateless traffic). In general, stateful traffic is more resource intensive for test equipment, so it is harder to achieve high enough offered load. Also, stateful traffic generation is more sensitive to packet loss and latency of SUT. [authors] This is not IMIX [3]. IMIX [3] defines based on variable packet sizes. But here in the draft, we define traffic mix based on different applications, and it's object sizes. For example an application mix can be HTTPS, HTTPS, DNS (UDP), VOIP (TCP and UDP), and, etc.). In this example we have a mix of stateful and stateless traffic and each application has different object sizes. One object can have multiple packets with different sizes. The packet sizes are dependent on multiple factors namely; TCP behavior, MTU size, total object size. Note: Stateful traffic generators MUST be used for all benchmarking tests and we used/are using stateful traffic generators for the NSO certification program. Vratko. [0] https://tools.ietf.org/html/rfc2285#section-3.6.1 [1] https://tools.ietf.org/html/rfc2285#section-3.5.2 [2] https://tools.ietf.org/html/rfc2544#section-26.1 [3] https://tools.ietf.org/html/rfc6985 -----Original Message----- From: bmwg <bmwg-bounces@ietf.org> On Behalf Of MORTON, ALFRED C (AL) Sent: Friday, 2020-December-18 19:16 To: bmwg@ietf.org Subject: [bmwg] WG Last Call: draft-ietf-bmwg-ngfw-performance-05 Hi BMWG, We will start a WG Last Call for Benchmarking Methodology for Network Security Device Performance https://tools.ietf.org/html/draft-ietf-bmwg-ngfw-performance-05 The WGLC will close on 22 January, 2021, allow for holidays and other competing topics (IOW, plenty of time!) Please read and express your opinion on whether or not this Internet-Draft should be forwarded to the Area Directors for publication as an Informational RFC. Send your comments to this list or to co-chairs at bmwg-chairs@ietf.com for the co-chairs, Al _______________________________________________ bmwg mailing list bmwg@ietf.org https://www.ietf.org/mailman/listinfo/bmwg _______________________________________________ bmwg mailing list bmwg@ietf.org https://www.ietf.org/mailman/listinfo/bmwg
- [bmwg] WG Last Call: draft-ietf-bmwg-ngfw-perform… MORTON, ALFRED C (AL)
- Re: [bmwg] WG Last Call: draft-ietf-bmwg-ngfw-per… Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco)
- Re: [bmwg] WG Last Call: draft-ietf-bmwg-ngfw-per… bmonkman
- Re: [bmwg] WG Last Call: draft-ietf-bmwg-ngfw-per… bmonkman
- Re: [bmwg] WG Last Call: draft-ietf-bmwg-ngfw-per… bmonkman
- Re: [bmwg] WG Last Call: draft-ietf-bmwg-ngfw-per… MORTON, ALFRED C (AL)
- Re: [bmwg] WG Last Call: draft-ietf-bmwg-ngfw-per… bmonkman
- Re: [bmwg] WG Last Call: draft-ietf-bmwg-ngfw-per… MORTON, ALFRED C (AL)
- Re: [bmwg] WG Last Call: draft-ietf-bmwg-ngfw-per… Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco)
- Re: [bmwg] WG Last Call: draft-ietf-bmwg-ngfw-per… Maciek Konstantynowicz (mkonstan)