class: center, middle # Neutron Quality of Service, new features and future roadmap .presenters[ * Miguel Ángel Ajo<br/> majopela@redhat.com * Sławek Kapłoński <br/> slawomir.kaplonski@ovh.net * Victor Howard <br/> victor_howard@cable.comcast.com ] --- # Agenda 1. QoS in Liberty - reminder 2. Mitaka: Bandwidth limit for LinuxBridge 2. Mitaka: The RBAC functionality 4. Newton: DSCP functionality 5. Newton and beyond --- name: qos_in_liberty_pre class: center # QoS in Liberty .left[ In the Liberty design summit, a model to provide quality of service in a gerneric way was proposed. ]  --- name: qos_in_liberty class: center # QoS in Liberty ## Egress bandwidth limit for: * Open vSwitch L2 agent * SR-IOV L2 agent ??? To say: * QoS only with one rule type: egress traffic limiting * implementation only for ovs and SR-IOV L2 agents. * Missing support for _LinuxBridge_ agent. * Implementation done as L2 extension drivers - new mechanism in Liberty --- class: center # Egress bandwidth limit rule: 1. Create policy ```bash neutron qos-policy-create example-policy ``` 2. Create bandwidth limit rule: ```bash neutron qos-bandwidth-limit-rule-create --max-kbps 512 \ --max-burst-kbps 1024 \ example-policy ``` 3. Apply policy for port/network ```bash neutron port-update 071e54ad-d5f5-402f-933f-dece0db3afde \ --qos-policy example-policy ``` ??? __Ask how many people know already QoS.__ Short remind. How QoS works in Neutron. If You want to configure bw... --- name: qos_bw_limit_ovs class: center # Apply egress bandwidth limit rule in Open vSwitch agent ```bash ovs-vsctl set Interface tap1 ingress_policing_rate=512 ovs-vsctl set Interface tap1 ingress_policing_burst=1024 ```  ??? On this picture You can see how VM is connected to network using OVS bridge. OVS L2 agent will apply bw limit from previous slide in two simple commands… Underneath ovs using TC to apply this ingress policing rules.... --- name: qos_linuxbridge_support_1 class: center # Egress bandwidth limit in Mitaka ## support for LinuxBridge L2 agent  ??? __And now here it comes.__ In Mitaka we provided support for QoS bw limit also in LB agent... --- name: qos_linuxbridge_details_1 class: center # QoS in LinuxBridge agent in details * LinuxBridge agent use tc (traffic control) Linux tool * policing on ingress qdisc (queueing discipline)  ??? qdisc is short for 'queueing discipline' and it is elementary to under- standing traffic control. Whenever the kernel needs to send a packet to an interface, it is enqueued to the qdisc configured for that inter- face. Immediately afterwards, the kernel tries to get as many packets as possible from the qdisc, for giving them to the network adaptor driver. (from tc manpage) __Tell about confusing thing here__ --- name: qos_how_tc_tbf_works class: center # How TBF qdisc works  source: http://unix.stackexchange.com/a/100797 ??? - There is metaphorical object called "bucket". Extra tokens are lost. - The size of the bucket is called burst. - When kernel wants to send packets to network, packets are enqueue in packet queue (qdisc). - In order to actually transmit a packet onto the network, that packet must obtain tokens equal to its size in bytes or mpu (whichever is larger). __Important setting here is value of burst:__ * too low - configured bw limit will not be reached * too high - too many packets will have tokens and bw_limit higher than expected --- name: qos_linuxbridge_details_2 class: center # Example with LinuxBridge agent: ```bash neutron qos-bandwidth-limit-rule-create --max-kbps 512 \ --max-burst-kbps 1024 \ example-policy ```  ```bash tc qdisc add dev tap ingress handle ffff: tc filter add dev tap parent ffff: protocol all prio 49 basic\ police rate 512kbit burst 1024kbit mtu 65535 drop ``` ??? So bw limit configured in Neutron with command ... will be applied by LB agent by executing ... To say: * In fact it makes exactly same TC command as Open vSwitch is doing so at the end limits are applied in exactly same way for both L2 agents. * MTU value here is the maximum packet size handled by the policer. Larger ones will be handled like they exceeded the configured rate, so will be dropped in our case. --- name: qos_in_mitaka class: center # QoS in Mitaka ## Egress bandwidth limit for: * Open vSwitch L2 agent * SR-IOV L2 agent * __LinuxBridge L2 agent__ ??? Finally in Mitaka all 3 main L2 agents from ML2 plugin supports Egress bw limit rule from QoS \o/ --- # Side effect: * L2 extension drivers in LinuxBridge agent * Fullstack tests for LinuxBridge agent ??? During the work on QoS for LB agent we achieved 2 other things... To say: * L2 extension drivers - tell that it's new in Liberty and QoS is implemented that way... * support for LB in fullstack tests --- name: rbac_in_mitaka # QoS in Mitaka: Role Based Access Control (RBAC) In the Liberty release, policies could be shared to all projects (tenants). ```bash $ neutron qos-policy-create shared-policy --shared ``` In *Mitaka*, thanks to RBAC integration, QoS policies can be shared to specific projects. ```bash $ neutron qos-policy-create the-policy $ neutron rbac-create --target-tenant <project-uuid> --action access_as_shared \ --type qos-policy <policy-uuid> _ ``` ??? Talk about how policy.json works, and how operators can modify that to allow non-administrator creating and sharing policies too. --- # Newton and beyond (rfe-approved) RFEs: http://bit.ly/neutron-qos-rfes-approved * DSCP marking rules (L3 marking) * Ingress bandwidth limiting ??? Explain what an RFE is: use case proposal, high level. --- # Newton: DSCP Use Case To specify and control network traffic by class to that certain types of traffic get precedence. For example voice traffic, which requires a relatively uninterrupted flow of data, might get precedence over other types of traffic. DSCP marking can also be used to mark traffic for security purposes. ??? Differentiated Services Code Point --- class: center # Newton: DSCP Marking Rule 1. Create policy ```bash neutron qos-policy-create dscp-marking ``` 2. Create DSCP marking rule: ```bash neutron qos-dscp-marking-rule-create dscp-marking --dscp-mark 26 ``` 3. Assign policy to a port ```bash openstack network port-update \ 48c6256f-9123-4e39-a321-108782807cfc --qos-policy dscp-marking ``` --- class: center name: dscp_diagram # Newton: DSCP Diagram  --- class: center name: dscp_policy # Newton: DSCP Policy to rules  --- # Newton: Ingress bandwidth limiting * data consuming apps: crawlers, dataminers, etc. * planning and allocation of bandwidth in general. ```bash neutron qos-bandwidth-limit-rule-create --max-kbps 512 \ --max-burst-kbps 1024 \ --direction ingress \ example-policy ``` * adds direction field to the bandwidth limit rule. * ingress * egress (default) ??? Note: SR-IOV does not suport ingress bw limit afaik, we may need to filter requests on ingress direction (or prevent it for vnic types other than vifs) --- # Newton and beyond (RFEs on flight) RFEs: http://bit.ly/neutron-qos-rfes * Minimum bandwidth support (egress) 1. In host (Best effort) 2. Scheduling aware (Strict) * Traffic classification * Rate limit external connectivity traffic * VLAN 802.1p support (L2 Marking) * Default policy for tenant * ECN integration --- # Newton RFE: Minimum bandwidth (egress) https://bugs.launchpad.net/neutron/+bug/1560963 <div id="graph-min-bw-best-eff"></div> --- name: bandwidth-scheduling-1 # Newton rfe: Minimum bandwidth (egress) (II) Strict bandwidth guarantee: scheduling aware  --- name: bandwidth-scheduling-2 # Newton rfe: Minimum bandwidth (egress) (III) Strict bandwidth guarantee: scheduling aware  --- name: bandwidth-scheduling-3 # Newton rfe: Minimum bandwidth (egress) (IV) Strict bandwidth guarantee: scheduling aware  --- name: bandwidth-scheduling-3b # Newton rfe: Minimum bandwidth (egress) (V) Strict bandwidth guarantee: scheduling aware  --- name: bandwidth-scheduling-4 # Newton rfe: Minimum bandwidth (egress) (VI) Strict bandwidth guarantee: scheduling aware  --- name: bandwidth-scheduling-5 # Newton rfe: Minimum bandwidth (egress) (VII) Strict bandwidth guarantee: scheduling aware  --- name: bandwidth-scheduling-6 # Newton rfe: Minimum bandwidth (egress) (VIII) Strict bandwidth guarantee: scheduling aware  --- name: bandwidth-scheduling # Newton rfe: Minimum bandwidth (egress) (IX) Strict bandwidth guarantee: integration with nova generic resource pools. * Bandwidth is modeled as a resource (NIC_BW) * Reported to nova generic resource pool API (when available) --- # Newton rfe: Traffic classification * Apply rules to specific traffic flows * Use cases: Prioritize certain traffic, like control, realtime data, etc. ### MODEL ``` +-----------+ +---------+ +-------------------+ | QosPolicy |--+--| QosRule |----| TrafficClassifier | (SSH) +-----------+ | +---------+ +-------------------+ | | +---------+ +-------------------+ +--| QosRule |----| TrafficClassifier | (HTTP) | +---------+ +-------------------+ | | +---------+ \--| QosRule | (all the other traffic) +---------+ ``` --- # Default policy for tenant Raw proposal: ```bash $ neutron qos-policy-create the-policy $ neutron rbac-create --target-tenant <project-uuid> --action default \ --type qos-policy <policy-uuid> $ ``` When the tenant creates a resource (port), it gets attached to this policy by default. --- # VLAN 802.1p Support * L2 level (in contrast with L3 of DSCP) * For vlan provider networks * Could be leveraged to prioritize tenant traffic segmented on vlan https://bugs.launchpad.net/neutron/+bug/1505631 --- # Rate limit external conectivity * Limit traffic speed at the border * It's problematic with distributed routing --- # Leveraging ECN * Still needs more definition * Better behaviour at the limit (instead of policing/dropping) --- # Questions? .presenters[ * Miguel Ángel Ajo<br/> majopela@redhat.com * Sławek Kapłoński <br/> slawomir.kaplonski@ovh.net * Victor Howard <br/> victor_howard@cable.comcast.com ] # Reference https://www.openstack.org/videos/video/neutron-dscp-policing-your-network http://slawqo.github.io/qos_presentation_austin_2016/