SONATA Profiler: Active PED

PED File for active profiling

Profiling experiment descriptors (PED) are YAML-based description files that define how a given network service should be automatically profiled. Each PED has some high-level descriptions fields, such as vendor, name, version, and thus follows the general design of all SONATA description files. In addition, a PED file contains a service_package field which contains a path to the service package to be used. In each PED file, a developer can define several service and/or function experiments. A service experiment is used to test or profile a complete network service chain which may consist of multiple VNFs. A function experiment, in contrast, is used to test or profile a singe function (a VNF) that is part of the given service. Each experiment contains a reference that either references the service (NSD) or function (VNFD) that should be used. Further, an experiment contains parameters, like experiment duration or a time_limit to define how long each configuration will be tested. Inside each experiment, a developer specifies the measurement points (MP) that should be connected to the service or function in order to send test traffic through them. Additionally, resource limitations can be specified to test VNFs with different resource configurations, e.g., test eu.sonata-nfv.fw-vnf.0.1 with 64 and 128 MB memory to obtain information about its scaling behaviour.

Example PED File

#
# This is an example for a profiling experiment descriptor (PED).
# It defines profiling experiments for the sonata-fw-vtc-service-emu example service.
#
descriptor_version: 0.1
# SONATA-like identifier (just in case we need it)
vendor: "eu.sonata-nfv"
name: "sonata-fw-vtc-profile-experiment"
version: "0.1"
author: "Manuel Peuster, Paderborn University, [email protected]"
description: "This is an example profiling experiment descriptor (PED)."

# path to the package of the service we want to profile
service_package: "./sonata-fw-vtc-service.son"

#
# First type of experiments: Service level experiments
#
service_experiments:
  - name: "service_throughput"
    description: "iperf test for entire service"
    repetitions: 1
    time_limit: "120"
    # NSD to be used (SONATA-like vendor.name.version reference)
    service: "eu.sonata-nfv.sonata-fw-vtc-service.0.1"
    # additional containers for traffic generation/measurements (like SAPs)
    measurement_points:
      - name: "mp.output"
        connection_point: "ns:serviceout"
        container: "mpeuster/p2-mp"
        cmd_start: ${"iperf -s"}
        cmd_stop: null
      - name: "mp.input"
        connection_point: "ns:servicein"
        container: "mpeuster/p2-mp"
        cmd_start: ${"iperf -c 1.1.1.1 -t 120", "iperf -c 1.1.1.1 -t 120 -u"}
        cmd_stop: null
    # resource configurations to be tested during profiling run (defined per VNF)
    resource_limitations:
      # again: SONATA-like references
      - function: "eu.sonata-nfv.fw-vnf.0.1"
        cpu_bw: "${0.05 to 0.1 step 0.05}" # Omnet++ style parameter study macros
        cpu_cores: 1
        mem_max: "${64, 128}" # Omnet++ style parameter study macros
        mem_swap_max: null
        io_bw: null
      - function: "eu.sonata-nfv.vtc-vnf.0.1"
        cpu_bw: "${0.05 to 0.1 step 0.05}"
        cpu_cores: 1
        mem_max: "${256, 512}"
        mem_swap_max: null
        io_bw: null
      - function: "mp.input"
        cpu_bw: 0.2
        cpu_cores: 1
        mem_max: 512
        mem_swap_max: null
        io_bw: null
      - function: "mp.output"
        cpu_bw: 0.2
        cpu_cores: 1
        mem_max: 512
        mem_swap_max: null
        io_bw: null