Qos Aggregated Bandwidth Rate Limiting

[vikram.choudhary]

[Existing problem]
In the current QoS implementation, network QoS bandwidth limit are applied to all the ports uniformly in the network. This may be wrong. Consider a case where the user just want 20 mbps speed for the entire network but the current implementation will end up in allowing 20 * num_of_ports_in_the_networks mbps.

[Proposal]
This proposal talks about the support for aggregated bandwidth rate limiting where all the ports in the network should together attain the specified network bandwidth limit. To start with an easiest implementation could be dividing the overall bandwidth value with the number of ports in the network. In this there might a case of over and under utilization which might need more thought (May be we got to monitor all the ports and have a notion of thresh hold to decide whether to increase or decrease the bandwidth)

[Benefits]
Better and correct user experience.

[What is the enhancement?]
Applying correct QoS rule parameter to each ports.

[Related information]
None

[vikram.choudhary (vikschw)]

Let's wait till the driver's team approve the rfe.
FYI: Slawek Kaplonski is already working on this.

[vikram.choudhary (vikschw)]

Spec is added for this effort: https://review.openstack.org/#/c/259916/

[Armando Migliaccio (armando-migliaccio)]

The way you describe it sounds like the initial QoS bandwidth limiting feature is grossly broken. I'd like someone from the QoS team to chime in. @Ajo, @Ihar, anyone else?

[Armando Migliaccio (armando-migliaccio)]

I don't understand why a spec is needed here. I am not even sure this is an RFE, and it looks like a regular bug, either in the code or in the documentation. Let's keep the discussion in one place, the spec provided provided very little extra context.

[Armando Migliaccio (armando-migliaccio)]

Let's continue the discussion, I think this can be easily dealt with clarifying the intention of the existing API, as it feels the only misunderstanding is the multiplier factor of the bandwidth limit.

[Irena Berezovsky (irenab)]

I think the way this issue is presented in a bit misleading. Currently, QoS bandwidth rate limit is supported on port level only. If network owner wants to have default port qos bw rate limit, he can apply qos policy to the network. This means that network assigned qos policy will be automatically assigned to the port. Per port setting can override the default setting. The case for aply network qos policy is not support.

[vikram.choudhary (vikschw)]

@Irena: To an end-user it might look odd. If we want to keep the current behaviour then let this documented clearly.

[Ihar Hrachyshka (ihar-hrachyshka)]

Vikram, where is it documented? Do you have a link that could show it's documented using bad wording?

Overall, the proposal probably talks about a completely separate qos rule, not changing behaviour for existing one. The proposal is not simple to implement. I see in the (now abandoned) spec, it's proposed that we make the number of ports in the network the decisive piece of data that defines the end bandwidth per port; and it's suggested that existing rpc callbacks mechanism would be used to propagate updates to effective policies on port C/U/D operations. I think that's the wrong perception of what rpc callbacks mechanism is about. It's not about pushing dynamic port policies into agents, but about synchronizing agents with current object state. In case when a policy is applied to a network, there is no port level policy applied. Would you suggest to add the number of ports in a network attribute to the rule object?.. That seems sick: you don't change rule db object state on port C/U/D.

I am also cautious about the whole suggested 'naive' approach where we divide the network bandwidth to the number of ports. If anything, this approach makes the network highly underutilized.

I would be more interested in discussing some realistic implementation for the feature, where you would actually dynamically monitor compute nodes and influence QoS attributes on ports throughout the cluster based on data collected on each node. That would avoid the issue of underutilization. That said, it's not easy at all: that would require some component to collect and disseminate the qos tweaks to l2 agents; so that would actually require a well thought spec.

[Miguel Angel Ajo (mangelajo)]

I agree with ihar here.

The current behaviour is defined here: http://docs.openstack.org/liberty/networking-guide/adv_config_qos.html "You can attach networks to a QoS policy. The meaning of this is that any compute port connected to the network will use the network policy by default unless the port has a specific policy attached to it. Network owned ports like dhcp and router ports are excluded from network policy application."

If you think we could enhance that wording feel free to suggest a new one.

In the other hand, just dividing the traffic among ports, seems like a very naive implementation which could lead to highly under-utilised network bandwidth. If we wanted to do aggregated network bandwidth shall we think about monitoring every port bw usage to adjust bitrates dynamically ?

[vikram.choudhary (vikschw)]

@Ajo: IMO, monitoring it dynamically would the best way to go forward.

[Armando Migliaccio (armando-migliaccio)]

Status update:

http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-02-11-22.00.log.html#l-166

[Armando Migliaccio (armando-migliaccio)]

If we want to be more explicit about this in the networking-guide and clarify the perceived side-effects of the existing implementation, then it's fine, but this is not exactly a neutron 'bug', but a documentation one.