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

From: "MORTON, ALFRED C (AL)" <[email-masked]>
Date: Mon, 11 Nov 2019 18:47:24 +0000

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).

---

From: Manuel Peuster <[email-masked]>
Date: Thu, 14 Nov 2019 14:27:55 +0100

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?

----

[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) <[email-masked]> wrote:
> 
> Hi Maciek and Peter,
> 
> ....
> ....
> ....
> ....
> _______________________________________________
> bmwg mailing list
> [email-masked]
> 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