yahoo-eng-team team mailing list archive

[Miguel Angel Ajo <majopela@xxxxxxxxxx>]

Public bug reported:

This RFE is a follow up of [1] and it's registered only for completion
to provide visibility on the high level plan. - we cannot tackle this
until [1] and [2] are in place. -

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


[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

** Affects: neutron
     Importance: Undecided
         Status: New


** Tags: qos rfe

** Tags added: qos rfe

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1578989

Title:
  [RFE] Strict minimum bandwidth support (egress)

Status in neutron:
  New

Bug description:
  This RFE is a follow up of [1] and it's registered only for completion
  to provide visibility on the high level plan. - we cannot tackle this
  until [1] and [2] are in place. -

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

  
  [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

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1578989/+subscriptions