yahoo-eng-team team mailing list archive

[Miguel Angel Ajo <majopela@xxxxxxxxxx>]

Public bug reported:

Minimum bandwidth support (opposed to bandwidth limiting), guarantees a
port minimum bandwidth when it's neighbours are consuming egress or
ingress 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 could be probably split
in two phases: strict, and non strict.

Use cases
========

NFV/telcos are interested in this type of rules (specially strict), 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
=====

Technologies like SR-IOV support that, and OVS & Linux bridge can be
configured to support this type of service. Where in OvS it requires to
use veth ports between bridges instead of patch ports, it introduces a
performance overhead of a ~20%. Supporting this kind of rule for OvS
agents must be made optional, so the administrators can choose it only
when they really need it.

SR-IOV seems not to incur in any performance penalty.

** Affects: neutron
     Importance: Undecided
         Status: New

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

Title:
  [RFE] Minimum bandwidth support

Status in neutron:
  New

Bug description:
  Minimum bandwidth support (opposed to bandwidth limiting), guarantees
  a port minimum bandwidth when it's neighbours are consuming egress or
  ingress 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 could be probably split
  in two phases: strict, and non strict.

  Use cases
  ========

  NFV/telcos are interested in this type of rules (specially strict), 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
  =====

  Technologies like SR-IOV support that, and OVS & Linux bridge can be
  configured to support this type of service. Where in OvS it requires
  to use veth ports between bridges instead of patch ports, it
  introduces a performance overhead of a ~20%. Supporting this kind of
  rule for OvS agents must be made optional, so the administrators can
  choose it only when they really need it.

  SR-IOV seems not to incur in any performance penalty.

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