Ability to mention Network IO Traffic Shaping rules as part of Security Group Rules

Registered by Sonu

Noisy neighbors is the term used to describe the phenomenon when many users share a medium and their usage of the medium leaves an impact on each others sharing the same medium.

In Cloud, the Compute, Network and Storage devices act like a shared medium. In IP networking, one solution to avoid the noisy neighbor is using 'Quality of Service (QoS)' which helps prioritize the network traffic so that the most important packets get through while the others get shaped. This is an important feature that almost all L2 bridges (eg:- OVS bridge) provides.

In openstack there exists no way for a Provider admin to configure and apply such traffic shaping rules.

Through this blue print, the proposal is to enable Provider and Tenant admins, define the traffic shaping rules as part of Security Group Rules and apply them seamlessly to a group of ports or individually to each port. Also, capability should be extended to allow a time window to mention the traffic limiting rules (for eg:- the rule applies during certain parts of the day)

Common scenarios where ingress and egress rate limiting would be used as listed below.

a) As a tenant admin, I would like to correctly estimate the network bandwidth requirements of my Virtual machine(s) as accurately as possible, however, would like to ensure that Virtual Machine(s) doing background data transfer activities (such as Background data transfer appliance, Storage replication, backup servers and so on) doesn't impact my VM(s) hosting my more relevant and critical business services during the peak times.

b) As a tenant/cloud provider admin, I want to ensure the major portion of the Network bandwidth is used by critical business service VM(s) during the peak times.

c) As a tenant provider admin, I want to analyse overall number of packets/traffic that were shaped due the traffic limiting rules, so that I can plan o expand my physical network device capacity to meet my demands in future.

Blueprint information

Status:
Complete
Approver:
Kyle Mestery
Priority:
Undefined
Drafter:
Sonu
Direction:
Needs approval
Assignee:
Sonu
Definition:
Obsolete
Series goal:
None
Implementation:
Unknown
Milestone target:
None
Completed by
Armando Migliaccio

Related branches

Sprints

Whiteboard

Nov-13-2015(armax): If someone is interested in pursuing it, this must be re-submitted according to guidelines defined in [1].

[1] http://docs.openstack.org/developer/neutron/policies/blueprints.html

-----------------

(?)

Work Items

Work items:
Traffic shaping rule model definition and introducing sg_rule type to note traffic shaping rules : TODO
Enabling neutron DB model to have traffic shaping rules along with the schedule parameters: TODO
Updating ML2 driver specification to notify all L2 agents, about the application of this new rule type. : TODO
Using per mechanism specific (OVS, Linux bride, iptables and so on) way to apply this rule native to the L2 agent. For example in case of OVS, 'ovs-vsctl set interface tap0 ingress_policing_rate=1000' to limit the flow on tap port 0 to 1 Mbps : TODO
ML2 plug in to notify L2 agents to change the traffic shaping rules as per the schedule.: TODO

This blueprint contains Public information 
Everyone can see this information.

Subscribers

No subscribers.