<div dir="ltr"><div><div><div><div><div>Hello All,<br><br></div>I think that the Neutron QoS effort is progressing into critical point and i asked Miguel if i could post an update on our progress.<br></div><br></div>First, i would like to thank Sean and Miguel for running this effort and everyone else that is involved, i personally think its on the right track, However i would like to see more people involved, especially more Neutron experienced members because i believe we want to make the right decisions and learn from past mistakes when making the API design.<br><br></div>Feel free to update in the meeting wiki [1], and the spec review [2]<br></div><br><div><b><u>Topics</u></b><br><br></div><div><span class=""><u>API microversioning spec implications [3]</u><br></span></div><div><span class="">QoS can benefit from this design, however some concerns were raised that this will<br></span></div><div><span class="">only be available at mid L cycle.<br></span></div><div><span class="">I think a better view is needed how this aligns with the new QoS design and<br></span></div><div><span class="">any feedback/recommendation is use full<br></span></div><div><br><span class=""><span class=""><u>Changes to the QoS API spec: scoping into bandwidth limiting</u><br>At this point the concentration is on the API and implementation<br></span></span></div><div><span class=""><span class="">of bandwidth limiting.<br><br></span></span></div><div><span class=""><span class="">However it is important to keep the design easily extensible for some next steps<br></span></span></div><div><span class=""><span class="">like traffic classification and marking<b>.<br></b></span></span><br><span class=""><span class=""><span class=""><u>Changes to the QoS API spec: modeling of rules (class hierarchy) (Guarantee split out)</u><br></span></span></span></div><div><span class=""><span class=""><span class="">There is a QoSPolicy which is composed of different QoSRules, there is<br></span></span></span></div><div><span class=""><span class=""><span class="">a discussion of splitting the rules into different types like QoS<Type>Rule.<br></span></span></span></div><div><span class=""><span class=""><span class="">(This in order to support easy extension of this model by adding new type <br></span></span></span></div><div><span class=""><span class=""><span class="">of rules which extend the possible parameters)<br><br></span></span></span></div><div><span class=""><span class=""><span class="">Plugins can then<b> </b></span></span></span><span class=""><span class=""><span class=""></span></span></span>separate optional aspects into separate rules.<br></div><div>Any feedback on this approach is appreciated.<br></div><div><br><span class=""><u>Discuss multiple API end points (per rule type) vs single</u><br></span></div><div><span class="">In summary this means  that in the above model, do we want to support<br></span></div><div><span class="">/v1/qosrule/..  or   /v1/qos<type>rule/ API's<br></span></div><div><span class="">I think the consensus right now is that the later is more flexible.<br><br></span></div><div><span class="">Miguel is also checking the possibility of using something like:<br></span></div><div><span class="">/v1/qosrule/type/... kind of parsing<br>Feedback is desired here too :)</span><b class=""><br></b></div><div><span class=""><span class=""></span></span></div><div><span class=""><span class=""></span></span><br><span class=""><span class=""><u>Traffic Classification considerations</u><br></span></span></div><div><span class=""><span class="">The idea right now is to extract the TC classification to another data model<br></span></span></div><div><span class=""><span class="">and attach it to rule<br></span></span></div><div><span class=""><span class="">that way </span></span>no need to repeat same filters for the same kind of traffic.<br><br></div><div>Of course we need to consider here what it means to "update" a classifier<br></div><div>and not to introduce too much dependencies<br></div><div><br><span class=""><u><span class=""><span class="">The ingress vs egress differences and issues</span></span></u><b class=""><br></b>Egress bandwidth limiting is much more use full and supported,<br></span></div><div><span class="">There is still doubt on the support of Ingress bandwidth limiting in OVS, anyone<br></span></div><div><span class="">that knows if Ingress QoS is supported in OVS we want your feedback :)<br></span></div><div><span class="">(For example implementing OF1.3 Metering spec)<br></span></div><div><span class=""><br>Thanks all (Miguel, Sean or anyone else, please update this if i forgot anything)<br></span></div><div><span class=""><br>[1] <a href="https://wiki.openstack.org/wiki/Meetings/QoS">https://wiki.openstack.org/wiki/Meetings/QoS</a><br>[2] </span><span class=""><a rel="nofollow" class="" href="https://review.openstack.org/#/c/88599/">https://review.openstack.org/#/c/88599/</a><br>[3] <a href="https://review.openstack.org/#/c/136760/">https://review.openstack.org/#/c/136760/</a></span><b class=""><br></b></div></div>