Re: [bmwg] Comments on draft-mkonstan-nf-service-density-01

Manuel Peuster <peuster@mail.uni-paderborn.de> Thu, 14 November 2019 13:28 UTC

Return-Path: <peuster@mail.uni-paderborn.de>
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 D0B66120112 for <bmwg@ietfa.amsl.com>; Thu, 14 Nov 2019 05:28:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mail.uni-paderborn.de
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 8sATUtmwJVDf for <bmwg@ietfa.amsl.com>; Thu, 14 Nov 2019 05:28:01 -0800 (PST)
Received: from collins.uni-paderborn.de (collins.uni-paderborn.de [IPv6:2001:638:502:c003::14]) (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 89E431200EF for <bmwg@ietf.org>; Thu, 14 Nov 2019 05:28:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mail.uni-paderborn.de; s=20170601; h=Message-Id:In-Reply-To:To:References: Date:Subject:Mime-Version:Content-Transfer-Encoding:Content-Type:From:Sender: Reply-To:Cc:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help: List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=f5Ncez47hNEkvtS2rb238BxyC6IMwA5yiV9X1OB542M=; b=cbCHu7SICxwGqzjZv5P5DH91lt LDPSCAeZJUW5bS0Oj+mIszZDcvdA6e7gnlGuogZoCYp1yOnrttNUEoDQjJy+yWPeHIrNQgqoQqE4E VWesySEl0gapOhHOkCsXU02Qg7PQgKMN2lWy3X+I7DyP0N3+UAmE07D8milaAFhH+/EU=;
From: Manuel Peuster <peuster@mail.uni-paderborn.de>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.8\))
Date: Thu, 14 Nov 2019 14:27:55 +0100
References: <4D7F4AD313D3FC43A053B309F97543CFA6EF4A7F@njmtexg5.research.att.com>
To: "bmwg@ietf.org" <bmwg@ietf.org>
In-Reply-To: <4D7F4AD313D3FC43A053B309F97543CFA6EF4A7F@njmtexg5.research.att.com>
Message-Id: <D81762D4-EEA1-4983-B89C-52DF35056ECC@mail.uni-paderborn.de>
X-Mailer: Apple Mail (2.3445.104.8)
X-IMT-Spam-Score: 0.0 ()
X-PMX-Version: 6.4.8.2820816, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2019.11.14.131817, AntiVirus-Engine: 5.68.0, AntiVirus-Data: 2019.11.13.5680001
X-IMT-Authenticated-Sender: uid=peuster,ou=People,o=upb,c=de
Archived-At: <https://mailarchive.ietf.org/arch/msg/bmwg/Ww0v1NABd2P81KD6DOMMtxlbmqk>
X-Mailman-Approved-At: Fri, 15 Nov 2019 04:44:35 -0800
Subject: Re: [bmwg] Comments on draft-mkonstan-nf-service-density-01
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, 14 Nov 2019 13:28:05 -0000

Hi  BMWG,

I read the draft about NFV service density benchmarking
(https://tools.ietf.org/html/draft-mkonstan-nf-service-density-01).
I think it is well written (I noticed some minor inconsistencies, e.g.,
vswitch vs. vSwitch that can be easily fixed).

Following  Al’s comments I compared the used terminology to our
draft about VNF benchmarking automation (draft-rosa-bmwg-vnfbench-05).
The terminologies are pretty well aligned and the understanding about what a
VNF/CNF is and how its resources are configured seem to be the same in
both drafts.

Some more comments:

========

3.2.  Configuration
…
   1.  Chain configuration:

       *  Relies on chain topology to form NFV service chains.

       *  NF packet forwarding designs:

          +  IPv4/IPv6 routing.

       *  Requirements for host data-plane:

          +  L2 switching with L2 forwarding context per each NF chain
             segment, or

          +  IPv4/IPv6 routing with IP forwarding context per each NF
             chain segment or per NF chain.

[mp]
I understand that using IPv4/IPv6 routing to do the forwarding designs is 
a good choice for initial benchmarking experiments. However, I was wondering
if (in the long run) service chaining technologies, like NSH (RFC8300) should be
considered here as well?

----

7.  Compute Resource Allocation

NFV Service Density - Core Usage View
   vSwitch-1c, NF-1c

   SVC   001   002   004   006   008   010
   001     2     3     6     9    12    15
   002     3     6    12    18    24    30

[mp]
As commented by Al, it was not clear for me at beginning why those numbers are
like this. But I think I then got it:

For 001/004: We have 4 * NS (each using 1PC per DT and a shared PC (S2PC) per MT which,
meaning 0.5PCs per MT). This results in 4 cores used by the 4 DTs and 2 cores used by the
4 MTs, summing up to 6 cores in total, no?

Maybe a brief example calculation would make this easier to understand for a reader.

====

Best
Manuel




> On 11. Nov 2019, at 19:47, MORTON, ALFRED C (AL) <acm@research.att.com>; wrote:
> 
> Hi Maciek and Peter,
> 
> My comments - promised at September ONS-EU - follow.
> 
> Al
> (as a Participant)
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 
> Hi BMWG,
> 
> This is a well-written draft, in formative stages. I'd like to 
> see other authors working in the network virtualization space
> look it over - see where you agree and not, etc.
> Our WG's products are better if they are consistent w.r.t.
> terminology, and avoid overlap as much as possible
> (through cross references).
> https://tools.ietf.org/html/draft-mkonstan-nf-service-density-01
> 
> 
> Al
> bmwg co-chair
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> 
> 1.  Terminology
> [acm]
> Section 1 should be a proper introduction.
> 
> [acm]
> I would like to see this draft align its many terms and definitions
> with existing definitions.  ETSI NFV has defined most, if not all
> in some form, NFV003 and TST009 are good places to start, but so are
> RFC8174 and RFC8204. Obviously, we want to reference RFC2544 and RFC2889
> where applicable, too.
> 
> [acm]
> Perhaps this section should become a Terminology Draft, expanded to cover 
> and avoid overlap with other work in progress:
>  https://tools.ietf.org/html/draft-dcn-bmwg-containerized-infra-03
> 
> 2.2
> ....
>             Figure 1. NFV software technology stack.
> 
>   Proposed methodology is complementary to existing NFV benchmarking
>   industry efforts focusing on vSwitch benchmarking [RFC8204], [TST009]
>   and extends the benchmarking scope to NFV services.
> [acm]
> Some of the TST009 Set-ups encourage testing of the "smaller"
> services envisioned here, with scale of many serial and parallel
> VNFs.
> 
> 
> 3.3.  Packet Path(s)
> 
> [acm]
> I think there is one variable possibly over-looked here,
> that is the number of ports on the VF used to attach to 
> the different data planes.
> For example, it's very common to have containers/pods
> with a single port/IP addrs on the Host data plane.
> A practical example is a small Web server, only needs 
> one port and IP addrs.
> - This question is kind of a test of how abstract 
>  the Network Service is, and how we answer is an 
>  important part of the NS definition.
> 
> 
> 5.  Host Networking
> 
>   Host networking data-plane is the central shared resource that
>   underpins creation of NFV services.  It handles all of the
>   connectivity to external physical network devices through physical
>   network connections using NICs, through which the benchmarking is
>   done.
> 
> ....
> 
>   o  Linux Kernel-Mode Networking.
> 
>   o  Linux User-Mode vSwitch.
> 
>   o  Virtual Machine vSwitch.
> 
>   o  Linux Container vSwitch.
> 
>   o  SRIOV NIC Virtual Function - note: restricted support for chain
>      and pipeline topologies, as it requires hair-pinning through the
>      NIC and oftentimes also through external physical switch.
> ....
>   Analysing properties of each of these options and their Pros/Cons for
>   specified NFV topologies and configurations is outside the scope of
>   this document.
> 
>   From all listed options, performance optimised Linux user-mode
>   vswitch deserves special attention.  Linux user-mode switch decouples
>   NFV service from the underlying NIC hardware, offers rich multi-
>   tenant functionality and most flexibility for supporting NFV
>   services.  But in the same time it is consuming compute resources and
>   is harder to benchmark in NFV service density scenarios.
> [acm]
> Could you say more about why this is harder to benchmark?
> I guess that DUT resources used and other unavoidable processes
> have conflicts during measurements, are there more problems?
> Also, I think that there may be potentially greater security
> risks for some choices, meaning fewer or redesigned options
> when it comes down to production deployment.
> 
> 
> 
> 7.  Compute Resource Allocation
> ....
>         +  PC - physical core, with SMT/HT enabled has many (mostly 2
>            today) logical cores associated with it.
> [acm]
> CPU Pinning to accomplish this, right?
> 
>         +  LC - logical core, if more than one lc get allocated in sets
>            of two sibling logical cores running on the same physical
>            core.
> [acm]
> CPU Pinning and additional vCPU assignment to accomplish this, right?
> 
>   NFV Service Density - Core Usage View
>   vSwitch-1c, NF-1c
> 
>   SVC   001   002   004   006   008   010
>   001     2     3     6     9    12    15
> [acm]
> Struggling to figure-out why the row below is not the answer.
> It must have something to do with the size of the NUMA node or ?
>   001     2     3     5     7     9    11
>   ???
> 
>   002     3     6    12    18    24    30
>   004     6    12    24    36    48    60
> 
> 
> 9.2.  Benchmarking MRR Throughput
> [acm]
> Probably the sample results should be in an Appendix.
> Put the graphs in slides of a BMWG presentation that
> can be referenced (IETF URLs are fairly persistent).
> 
> 
> _______________________________________________
> bmwg mailing list
> bmwg@ietf.org
> https://www.ietf.org/mailman/listinfo/bmwg

--
Manuel Peuster, M.Sc.
Paderborn University
Computer Networks Group
Phone: +49 5251 / 604341
Web: https://peuster.de
Room: O3.170