This bug has been migrated to another issue tracking site. It has been closed here and may no longer be being monitored.

If you would like to get updates for this issue, or to participate in it, you may do so at Red Hat Issue Tracker .
Bug 1955197 - [RFE] Strict minimum bandwidth support (egress)
Summary: [RFE] Strict minimum bandwidth support (egress)
Keywords:
Status: CLOSED MIGRATED
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 16.1 (Train)
Hardware: All
OS: Linux
unspecified
low
Target Milestone: ---
: ---
Assignee: OSP Team
QA Contact: Eran Kuris
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-04-29 16:49 UTC by Siggy Sigwald
Modified: 2023-10-20 19:12 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-10-20 19:10:32 UTC
Target Upstream Version:
Embargoed:
gurpsing: needinfo-

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1578989 0 None None None 2021-04-29 16:49:02 UTC
Red Hat Issue Tracker OSP-29922 0 None None None 2023-10-20 19:12:31 UTC
Red Hat Issue Tracker OSP-3479 0 None None None 2022-03-24 13:39:23 UTC
Red Hat Issue Tracker   OSPRH-507 0 None None None 2023-10-20 19:10:31 UTC

Description Siggy Sigwald 2021-04-29 16:49:03 UTC 
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
Note You need to log in before you can comment on or make changes to this bug.