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

[Manuel Peuster <[e-mail]>]

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) <[e-mail]> 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
> [e-mail]
> 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