Activity log for bug #1560963

Date Who What changed Old value New value Message
2016-03-23 12:53:39 Miguel Angel Ajo bug added bug
2016-03-23 13:34:31 Henry Gessau neutron: status New Confirmed
2016-03-23 13:34:35 Henry Gessau neutron: importance Undecided Wishlist
2016-03-23 13:35:26 Henry Gessau tags qos
2016-03-30 08:46:58 Miguel Angel Ajo summary [RFE] Minimum bandwidth support [RFE] Minimum bandwidth support (ingress)
2016-03-30 08:49:55 Miguel Angel Ajo 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. 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. This RFE title has been corrected to tackle only with instance-egress traffic, as per comments #1 and #2 of this rfe/bug, ingress is problematic, and even if it can be tackled, it's a much more complex beast, @armax knows about it [1] [1] https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/supporting-network-bandwidth-guarantees-with-openstack-an-implementation-perspective
2016-03-30 08:50:37 Miguel Angel Ajo 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. This RFE title has been corrected to tackle only with instance-egress traffic, as per comments #1 and #2 of this rfe/bug, ingress is problematic, and even if it can be tackled, it's a much more complex beast, @armax knows about it [1] [1] https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/supporting-network-bandwidth-guarantees-with-openstack-an-implementation-perspective 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 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. This RFE title has been corrected to tackle only with instance-egress traffic, as per comments #1 and #2 of this rfe/bug, ingress is problematic, and even if it can be tackled, it's a much more complex beast, @armax knows about it [1]  [1] https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/supporting-network-bandwidth-guarantees-with-openstack-an-implementation-perspective
2016-03-30 11:41:06 Miguel Angel Ajo summary [RFE] Minimum bandwidth support (ingress) [RFE] Minimum bandwidth support (egress)
2016-04-13 07:46:25 Mathieu Rohon bug added subscriber Mathieu Rohon
2016-04-20 12:23:22 Miguel Angel Ajo tags qos qos rfe
2016-05-04 09:51:32 Rodolfo Alonso neutron: assignee Rodolfo Alonso (rodolfo-alonso-hernandez)
2016-05-06 09:31:35 Miguel Angel Ajo description 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 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. This RFE title has been corrected to tackle only with instance-egress traffic, as per comments #1 and #2 of this rfe/bug, ingress is problematic, and even if it can be tackled, it's a much more complex beast, @armax knows about it [1]  [1] https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/supporting-network-bandwidth-guarantees-with-openstack-an-implementation-perspective 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 addresses only the hypervisor side of it. Scheduling cooperation will be addressed in a separate RFE, this work is a pre-requisite for the 2nd step. 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 ===== 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. This RFE title has been corrected to tackle only with instance-egress traffic, as per comments #1 and #2 of this rfe/bug, ingress is problematic, and even if it can be tackled, it's a much more complex beast, @armax knows about it [1]  [1] https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/supporting-network-bandwidth-guarantees-with-openstack-an-implementation-perspective
2016-05-06 09:47:08 Miguel Angel Ajo description 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 addresses only the hypervisor side of it. Scheduling cooperation will be addressed in a separate RFE, this work is a pre-requisite for the 2nd step. 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 ===== 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. This RFE title has been corrected to tackle only with instance-egress traffic, as per comments #1 and #2 of this rfe/bug, ingress is problematic, and even if it can be tackled, it's a much more complex beast, @armax knows about it [1]  [1] https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/supporting-network-bandwidth-guarantees-with-openstack-an-implementation-perspective 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 addresses only the hypervisor side of it. Scheduling cooperation will be addressed in a separate RFE [2] , this work is a pre-requisite for the 2nd step. 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. This RFE is a prerequisite for [1]. Which in the mean time will provide a best effort guarantee on minimum bandwidth. 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. This RFE title has been corrected to tackle only with instance-egress traffic, as per comments #1 and #2 of this rfe/bug, ingress is problematic, and even if it can be tackled, it's a much more complex beast, @armax knows about it [1] [1] https://www.openstack.org/summit/vancouver-2015/summit-videos/presentation/supporting-network-bandwidth-guarantees-with-openstack-an-implementation-perspective [2] https://bugs.launchpad.net/neutron/+bug/1578989
2016-05-19 09:29:31 OpenStack Infra neutron: status Confirmed In Progress
2016-05-19 20:55:53 Armando Migliaccio neutron: status In Progress Confirmed
2016-05-26 17:33:14 Armando Migliaccio neutron: status Confirmed Triaged
2016-05-27 18:09:27 Armando Migliaccio tags qos rfe qos rfe-approved
2016-05-27 18:09:33 Armando Migliaccio neutron: milestone newton-1
2016-06-01 09:25:58 OpenStack Infra neutron: status Triaged In Progress
2016-06-03 19:34:58 Armando Migliaccio neutron: milestone newton-1 newton-2
2016-06-07 14:29:01 Francisco Garcia bug added subscriber Francisco Garcia
2016-07-15 23:34:35 Armando Migliaccio neutron: milestone newton-2 newton-3
2016-08-29 14:02:59 OpenStack Infra neutron: assignee Rodolfo Alonso (rodolfo-alonso-hernandez) David Shaughnessy (david-shaughnessy)
2016-08-29 18:26:19 OpenStack Infra neutron: assignee David Shaughnessy (david-shaughnessy) Ihar Hrachyshka (ihar-hrachyshka)
2016-08-30 12:08:34 Ihar Hrachyshka neutron: assignee Ihar Hrachyshka (ihar-hrachyshka) Rodolfo Alonso (rodolfo-alonso-hernandez)
2016-09-01 07:54:54 OpenStack Infra neutron: assignee Rodolfo Alonso (rodolfo-alonso-hernandez) Ihar Hrachyshka (ihar-hrachyshka)
2016-09-01 20:12:20 Armando Migliaccio neutron: milestone newton-3 newton-rc1
2016-09-02 06:22:29 OpenStack Infra neutron: assignee Ihar Hrachyshka (ihar-hrachyshka) Hirofumi Ichihara (ichihara-hirofumi)
2016-09-08 14:48:43 OpenStack Infra neutron: assignee Hirofumi Ichihara (ichihara-hirofumi) Rodolfo Alonso (rodolfo-alonso-hernandez)
2016-09-13 00:53:36 Armando Migliaccio neutron: status In Progress Fix Released
2017-02-02 00:53:35 Ihar Hrachyshka tags qos rfe-approved neutron-proactive-backport-potential qos rfe-approved
2017-02-10 17:22:02 Armando Migliaccio neutron: milestone newton-rc1 pike-1
2017-02-10 17:22:05 Armando Migliaccio neutron: status Fix Released In Progress
2017-05-18 01:20:09 Armando Migliaccio neutron: milestone pike-1 pike-2
2017-12-05 15:06:06 Slawek Kaplonski neutron: assignee Rodolfo Alonso (rodolfo-alonso-hernandez)
2018-01-02 12:57:40 Slawek Kaplonski neutron: milestone pike-2
2018-08-30 13:28:43 Christophe Fontaine bug added subscriber Christophe Fontaine
2018-11-08 17:46:57 OpenStack Infra neutron: assignee Rodolfo Alonso (rodolfo-alonso-hernandez)