Comment 7 for bug 1787793

@Slawek Kaplonski, bandwidth quota can be introduced to the neutron, since users can not use it unrestrainedly. But user may complain why pay for a large bandwith quota but not acctually use it.

@zhaobo, bandwidth share corss floating IPs in dvr scenario seems also not easy to implement in the neutron scope. For that tc-wrapper, I think it can be useful for the traffic sharping, average, minimum bandwidth assurence etc. Hmm, for that physic devices, it can be managed by many plugins for neutron, such as ovn, midonet, odl etc. So we can say it is a cloud. ;-)

If the VPN qos only care about the traffic of the VPN connections, then it can be implemented as a new L3 agent extension. GW IP qos is aim to the router gateway IP, it will limit all the traffic throuth that IP so it will include the VPN traffic. It's a L3 agent extension too. So I think maybe the VPN qos will install the tc rules to the same namespace and same device? So here we are now facing conflicts between the existing TC rules with the new tc-wrapper classful rules？Right? If so, maybe change the device or namespace for the VPN qos can skip such issue. If not, just do it. Let the cloud administor to decide which L3 extension he want use. : )