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

["MORTON, ALFRED C (AL)" <[e-mail]>]

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