Re: [bmwg] WG Last Call: draft-ietf-bmwg-ngfw-performance-05

"MORTON, ALFRED C (AL)" <acm@research.att.com> Tue, 12 January 2021 15:41 UTC

Return-Path: <acm@research.att.com>
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 755EB3A0962 for <bmwg@ietfa.amsl.com>; Tue, 12 Jan 2021 07:41:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 GPGNhoVzWe-2 for <bmwg@ietfa.amsl.com>; Tue, 12 Jan 2021 07:41:38 -0800 (PST)
Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (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 050093A0957 for <bmwg@ietf.org>; Tue, 12 Jan 2021 07:41:37 -0800 (PST)
Received: from pps.filterd (m0083689.ppops.net [127.0.0.1]) by m0083689.ppops.net-00191d01. (8.16.0.43/8.16.0.43) with SMTP id 10CFYhkY027214; Tue, 12 Jan 2021 10:41:34 -0500
Received: from tlpd255.enaf.dadc.sbc.com (sbcsmtp3.sbc.com [144.160.112.28]) by m0083689.ppops.net-00191d01. with ESMTP id 35yt9f9rgu-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 12 Jan 2021 10:41:33 -0500
Received: from enaf.dadc.sbc.com (localhost [127.0.0.1]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 10CFfX8Q016649; Tue, 12 Jan 2021 09:41:33 -0600
Received: from zlp30496.vci.att.com (zlp30496.vci.att.com [135.46.181.157]) by tlpd255.enaf.dadc.sbc.com (8.14.5/8.14.5) with ESMTP id 10CFfSlP016528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 12 Jan 2021 09:41:29 -0600
Received: from zlp30496.vci.att.com (zlp30496.vci.att.com [127.0.0.1]) by zlp30496.vci.att.com (Service) with ESMTP id CD5DB403A423; Tue, 12 Jan 2021 15:41:28 +0000 (GMT)
Received: from clph811.sldc.sbc.com (unknown [135.41.107.12]) by zlp30496.vci.att.com (Service) with ESMTP id 96235403A422; Tue, 12 Jan 2021 15:41:28 +0000 (GMT)
Received: from sldc.sbc.com (localhost [127.0.0.1]) by clph811.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 10CFfSiV075976; Tue, 12 Jan 2021 09:41:28 -0600
Received: from mail-azure.research.att.com (mail-azure.research.att.com [135.207.255.18]) by clph811.sldc.sbc.com (8.14.5/8.14.5) with ESMTP id 10CFfLoF075491; Tue, 12 Jan 2021 09:41:22 -0600
Received: from exchange.research.att.com (njbdcas1.research.att.com [135.197.255.61]) by mail-azure.research.att.com (Postfix) with ESMTP id D494B10A18F2; Tue, 12 Jan 2021 10:41:20 -0500 (EST)
Received: from njmtexg5.research.att.com ([fe80::b09c:ff13:4487:78b6]) by njbdcas1.research.att.com ([fe80::8c6b:4b77:618f:9a01%11]) with mapi id 14.03.0468.000; Tue, 12 Jan 2021 10:41:28 -0500
From: "MORTON, ALFRED C (AL)" <acm@research.att.com>
To: "bmonkman@netsecopen.org" <bmonkman@netsecopen.org>, "bmwg@ietf.org" <bmwg@ietf.org>
CC: "'Bala Balarajah'" <bala@netsecopen.org>, "'Carsten Rossenhoevel'" <cross@eantc.de>
Thread-Topic: [bmwg] WG Last Call: draft-ietf-bmwg-ngfw-performance-05
Thread-Index: AdbVaOpmEZGSxNP5RqaYpjPM2pFdlwDvlSmwAEQ4xwADup8RgAAKZoVw
Date: Tue, 12 Jan 2021 15:41:28 +0000
Message-ID: <4D7F4AD313D3FC43A053B309F97543CF0147687D62@njmtexg5.research.att.com>
References: <4D7F4AD313D3FC43A053B309F97543CF014767877B@njmtexg5.research.att.com> <BY5PR11MB4038A9A8D3A833F8AA2B03A7BDDE0@BY5PR11MB4038.namprd11.prod.outlook.com> <027801d6da0e$3ac20740$b04615c0$@netsecopen.org> <018201d6e8f8$b69e2800$23da7800$@netsecopen.org>
In-Reply-To: <018201d6e8f8$b69e2800$23da7800$@netsecopen.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [24.148.42.167]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.343, 18.0.737 definitions=2021-01-12_10:2021-01-12, 2021-01-12 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 phishscore=0 lowpriorityscore=0 suspectscore=0 spamscore=0 impostorscore=0 mlxlogscore=999 bulkscore=0 clxscore=1011 adultscore=0 mlxscore=0 malwarescore=0 priorityscore=1501 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2101120090
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/lUUfaSHN4zWX2XhaXdF1DuKZNwU>
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: Tue, 12 Jan 2021 15:41:41 -0000

Hi Brian,

> The WGLC will close on 22 January, 2021, allow for holidays and other
competing topics.

I continue to plan to review sections that I have not reviewed in the past.

It is almost always better to keep the same version for the entire WGLC, so that's what I suggest :-) but I'm glad to hear that you have executed many changes to keep up with the comments!

Al


> -----Original Message-----
> From: bmonkman@netsecopen.org [mailto:bmonkman@netsecopen.org]
> Sent: Tuesday, January 12, 2021 10:37 AM
> To: bmwg@ietf.org; MORTON, ALFRED C (AL) <acm@research.att.com>
> Cc: 'Bala Balarajah' <bala@netsecopen.org>rg>; 'Carsten Rossenhoevel'
> <cross@eantc.de>
> Subject: RE: [bmwg] WG Last Call: draft-ietf-bmwg-ngfw-performance-05
> 
> Al et al,
> 
> Given that there have been no further comments we will update the draft
> and
> post it for, hopefully, final review.
> 
> Brian
> 
> -----Original Message-----
> From: bmonkman@netsecopen.org <bmonkman@netsecopen.org>
> Sent: December 24, 2020 11:03 AM
> To: 'Vratko Polak -X (vrpolak - PANTHEON TECH SRO at Cisco)'
> <vrpolak=40cisco.com@dmarc.ietf.org>rg>; bmwg@ietf.org
> Cc: 'MORTON, ALFRED C (AL)' <acm@research.att.com>om>; 'Bala Balarajah'
> <bala@netsecopen.org>rg>; 'Carsten Rossenhoevel' <cross@eantc.de>
> Subject: RE: [bmwg] WG Last Call: draft-ietf-bmwg-ngfw-performance-05
> 
> 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://urldefense.com/v3/__https://tools.ietf.org/html/rfc2285*section-
> 3.6.1__;Iw!!BhdT!ycNEmzrmfiwdpp-
> 9vduF8oGkZmLCdHFdWLPW7AXW6BOzFW4leuw1EQ6cf_9LAsk$
> [1]
> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc2285*section-
> 3.5.2__;Iw!!BhdT!ycNEmzrmfiwdpp-
> 9vduF8oGkZmLCdHFdWLPW7AXW6BOzFW4leuw1EQ6cHitzC1w$
> [2]
> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc2544*section-
> 26.1__;Iw!!BhdT!ycNEmzrmfiwdpp-
> 9vduF8oGkZmLCdHFdWLPW7AXW6BOzFW4leuw1EQ6cm06wZVM$
> [3]
> https://urldefense.com/v3/__https://tools.ietf.org/html/rfc6985__;!!BhdT!y
> cNEmzrmfiwdpp-9vduF8oGkZmLCdHFdWLPW7AXW6BOzFW4leuw1EQ6cDmT8_Wg$
> 
> -----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://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-bmwg-
> ngfw-performance-05__;!!BhdT!ycNEmzrmfiwdpp-
> 9vduF8oGkZmLCdHFdWLPW7AXW6BOzFW4leuw1EQ6cIm1m1L8$
> 
> 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://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bmwg__;!
> !BhdT!ycNEmzrmfiwdpp-9vduF8oGkZmLCdHFdWLPW7AXW6BOzFW4leuw1EQ6cuBcgfP4$
> _______________________________________________
> bmwg mailing list
> bmwg@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/bmwg__;!
> !BhdT!ycNEmzrmfiwdpp-9vduF8oGkZmLCdHFdWLPW7AXW6BOzFW4leuw1EQ6cuBcgfP4$
>