[RFE][QoS] Add minimum guaranteed packet rate QoS rule
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
neutron |
In Progress
|
Undecided
|
Przemyslaw Szczerbik |
Bug Description
Quote from "[RFE] [QoS] add qos rule type packet per second (pps)" [1]:
For cloud providers, to limit the packet per second (pps) of VM NIC is popular and sometimes essential. Transit large set packets for VM in physical compute hosts will consume the CPU/phy-nic performance. And for small packets, even the bandwidth is low, the pps can still be higher, which can be an attact point inside the cloud while some VMs are becoming hacked.
--
Neutron already supports bandwidth_limit and minimum_bandwidth QoS rules.
So [1] proposes a packet rate limit QoS rule. With similar reasoning and aligning with the existing bandwidth rules providing minimum packet rate QoS rule could also make sense.
The new minimum_packet_rate rule has a similar structure and semantic as the minimum_bandwidth rule:
* It defines a guaranteed minimum packet rate in kpps
* It defines a direction (egress / ingress) to which direction the guarantee is applied.
E.g.:
POST /v2.0/qos/
{
"
}
}
* Ports with such QoS rule expected to be scheduled on compute nodes where the networking backend (typically OVS) still has enough packet processing capacity to fulfill the guarantee.
This RFE is focusing on supporting min guaranteed packet rate for OVS network backend only.
A new config option is introduced in the OVS agent configuration where the admin can define the available packet processing capacity of the OVS deployed on the given compute host. This information is sent to the neutron server in the agent hearth beat. The neutron server uses this information to create NET_KILOPACKET_
Note that the resource inventory is directionless, while the proposed QoS rule has direction. From scheduling perspective the direction of the QoS rule does not matter and both direction will be counted against the single directionless resource inventory. However for data plane enforcement directions should be handled separately.
Note that while bandwidth inventory is define per bridge / physical device the packet processing capacity is applied globally to the whole OVS instance.
A port that has such QoS policy rule needs to express the related NET_KILOPACKET_
"resource_request":
{
"required": ["CUSTOM_
"resources": {"NET_BW_
},
to:
"resource_request":
{
{
"name": <some port unique name, e.g. the policy rule id that requesting the resource>
"required": [],
},
{
"name": <some port unique name, e.g. the policy rule id that requesting the resource>
"required": ["CUSTOM_
},
},
As a consequence the port bindig:
Enforcing the packet rate guarantees on the data plane is out of scope of this RFE. In the future a basic guarantee can be provided in the networking backend by re-using the data plane enforcement implementation of the packet_rate_limit rule from [1].
I will propose a nova-spec under the bp[2] that will define both the high level solution and the details of the nova impact. Also I will propose a neutron-spec defining the detailed impact on neutron.
[1] https:/
[2] https:/
tags: | added: rfe |
tags: |
added: rfe-approved removed: rfe-triaged |
Changed in neutron: | |
milestone: | none → next |
Changed in neutron: | |
assignee: | nobody → Przemyslaw Szczerbik (pszczerbik) |
+1
We will have pps support, then we should add ability to support minimum guaranteed pps. Otherwise, each instances will break the limitation for no guarantee anymore.