Uploaded image for project: 'Red Hat OpenStack Services on OpenShift'
  1. Red Hat OpenStack Services on OpenShift
  2. OSPRH-507

[RFE][OVN] Strict minimum bandwidth support (egress) Tech Preview

XMLWordPrintable

    • Strict minimum bandwidth support
    • 5
    • False
    • False
    • Committed
    • Committed
    • Committed
    • Committed
    • 0% To Do, 0% In Progress, 100% Done
    • Hide
      .QoS minimum bandwidth policy (technology preview)

      In RHOSO 18.0.0, a technology preview is available for the Networking service (neutron) for QoS minimum bandwidth for placement reporting and scheduling.
      Show
      .QoS minimum bandwidth policy (technology preview) In RHOSO 18.0.0, a technology preview is available for the Networking service (neutron) for QoS minimum bandwidth for placement reporting and scheduling.
    • Technology Preview
    • Proposed

      This Epic is to cover Tech Preview feature availability. GA will be covered in a later release. 

      Customer is looking for a way to ensure ports are created taking into account existing network use and b/w requested.

      Minimum bandwidth support (opposed to bandwidth limiting), guarantees a port minimum bandwidth when it's neighbours are consuming egress traffic and can be throttled in favor of the guaranteed port.

      Strict minimum bandwidth support requires scheduling cooperation, to avoid physical interfaces overcommit. This RFE assumes that the hypervisor side of it is handled as per [1]

      Use cases
      ========

      NFV/telcos are interested in this type of rules to make sure functions don't overcommit computes, and that any spawn of the same architecture will perform exactly as expected.

      CSP could make use of it to provide guaranteed bandwidth for streaming, etc...

      Notes
      =====

      This depends on the nova generic resource pool framework to be available [2], an specific resource (attached to compute nodes NIC_BW) being declared by neutron (as per discovery or admin setting on each host)

      Also, a mechanism for nova scheduler to be able to understand the amount of resources consumed from a port will be necessary. Either as a detail that is provided in the port when nova is calling neutron for port creation/get, or as a separate call [3].

      Nova dependencies
      =================

      Custom resource classes:
      Spec: https://review.openstack.org/#/c/312696/
      Code: https://review.openstack.org/#/q/topic:bp/custom-resource-classes

      Nested resource providers:

      Spec: https://review.openstack.org/#/c/386710/
      Code: https://review.openstack.org/#/q/topic:bp/nested-resource-providers

      for example:
      NIC_BW_EGRESS.<physnet>
      NIC_BW_INGRESS.<physnet>

      [1] https://bugs.launchpad.net/neutron/+bug/1560963
      [2] http://lists.openstack.org/pipermail/openstack-dev/2016-February/086371.html
      [3] http://lists.openstack.org/pipermail/openstack-dev/2016-April/091928.html

              rodolfo_alonso Rodolfo Alonso
              jira-bugzilla-migration RH Bugzilla Integration
              rhos-dfg-networking-squad-neutron
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: