14:01:30 <ajo> #startmeeting neutron_qos
14:01:32 <openstack> Meeting started Wed Apr 29 14:01:30 2015 UTC and is due to finish in 60 minutes.  The chair is ajo. Information about MeetBot at http://wiki.debian.org/MeetBot.
14:01:33 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
14:01:35 <openstack> The meeting name has been set to 'neutron_qos'
14:01:47 <sadasu> Hello!
14:01:51 <gsagie> hi
14:01:52 <ajo> #topic Announcements
14:01:52 <ajo> #link https://wiki.openstack.org/wiki/Meetings/NeutronQoS
14:01:54 <ajo> #link https://etherpad.openstack.org/p/neutron-liberty-qos-code-sprint
14:02:15 <ajo> :-) I wanted to spam as usual about the sprint, if anybody want to join and didn't sign up yet, do it :)
14:02:27 <ajo> #topic High level api/cmdline overview, to share with operators
14:02:27 <ajo> #link https://etherpad.openstack.org/p/neutron-qos-api-preview
14:02:45 <garyk> hi
14:02:49 <moshele> hi
14:02:51 <irenab> hi
14:02:55 <ajo> hi garyk, sorry, may be I was running too much :)
14:03:05 <ajo> I just posted: https://etherpad.openstack.org/p/neutron-qos-api-preview
14:03:20 <gsagie> just a suggestion as i wrote in message, make the unit a field and then "max", "max_burst"...
14:03:33 <gsagie> and unit can be Kb, Mb...
14:03:45 <ajo> gsagie, yes I thought of it, but I believe we shall not complicate ourselves adding unit management
14:03:53 <sc68cal> hi
14:03:56 <garyk> ajo: is that egress or ingress or both directions?
14:04:00 <ajo> if we pick one , it's uniform across all
14:04:00 <vhoward> hey ajo
14:04:22 <ajo> garyk, the current definition is egress,
14:04:37 <ajo> but we could extend it in the future, as we plan to do with protocol / port matching, etc
14:04:44 <garyk> ok, thanks, any reason why we do not allow for igress?
14:05:30 <ajo> garyk, I didn't have time to experiment with the ref implementation to provide ingress, but we could extend to support it
14:05:41 <garyk> ajo: ok, thanks
14:05:51 <garyk> sorry for jumping in very late… but does not harm to ask
14:05:57 <ajo> I guess it's just basically adding another queue, and moving traffic going to the mac into the queue
14:05:58 <irenab> ajo: shall we have direction as part of API?
14:06:17 <ajo> irenab, may be we should consider that field in this first iteration
14:06:20 <ajo> to make it clear
14:06:30 <ajo> I believe it's a good suggestion
14:06:55 <vikram__> +1
14:06:57 <ajo> #action ajo add direction field to QoSRules (ingress/egress)
14:07:02 <garyk> ajo: irenab: one more question (which maybe i missed) is this per port per network?
14:07:10 <ajo> garyk per port
14:07:19 <garyk> ok, thanks
14:07:27 <ajo> garyk, you could attach a policy to a network, but that means all ports in that network will be applied the policy
14:07:37 <ajo> no consideration for agregated bandwidth at this time
14:07:43 <irenab> per network qos will just be applied on each port that does not have its own qos policy associated
14:07:44 <garyk> would it be possible to define it globally on the network and then each port can inherit the global policy?
14:07:59 <garyk> irenab: ok, thanks, that answers the question :)
14:07:59 <vikram__> i have a doubt..
14:08:05 <ajo> garyk, that's the plan, but bandwidth is accounted locally to each port.
14:08:14 <garyk> ok
14:08:31 <vikram__> if ratelimiting for network-100mbps and for port=200mbps which will be considered
14:08:42 <ajo> garyk, may be at a later time we can come out with a way to have "agregated network bw limits" but not sure how to do it on the low level I guess is a complicated topic
14:08:44 <sc68cal> port overrides network policy
14:09:00 <garyk> ajo: ok
14:09:06 <ajo> the spec currently says, port config overrides network config
14:09:14 <vikram__> but overall n/w is configured to support only 100
14:09:28 <vikram__> is this a misconfiguration?
14:09:32 <vikram__> do we need to handle
14:09:33 <sc68cal> vikram__: so every port on the network except that port gets 100
14:09:33 <garyk> vikram__: i think that is per virtual port
14:09:48 <sc68cal> the port with the 200 gets 200
14:10:26 <ajo> In some cases we could think of blending rules...
14:10:28 <ajo> if that makes sense
14:10:29 <irenab> I think the idea of per network setting is some sort of ‘use network setting as port default setting if not specified otherwise'
14:10:39 <ajo> I considered it at the start, but I had negative comments in the spec
14:10:54 <ajo> for the bw limiting case, it's easy to do, just get the min of all parameters
14:11:08 <ajo> for other cases, for example dscp marking, it couldn't be blended
14:11:34 <ajo> what do you think about blending policies?
14:11:34 <vikram__> ok
14:11:44 <ajo> I'm ok with port setting overrides net setiting
14:11:52 <ajo> setting
14:12:27 <ajo> any feedback related to blending?
14:13:06 <ajo> if anybody thinks blending is important, please think about use cases, and how to handle conflicts in other rule types
14:13:10 <ajo> ok, let's move on
14:13:22 <ajo> #topic Update on latest changes to models
14:13:32 <ajo> I have modified the models to be
14:13:38 <ajo> QoSPolicy and QoSRule
14:13:48 <ajo> before they were QoSProfile and QoSPolicy
14:14:01 <ajo> I believe this is more similar to the language of security groups
14:14:22 <ajo> and thus be more usable because we're sharing the concepts
14:14:28 <vikram__> easy to understand as well:)
14:14:36 <ajo> :-)
14:14:39 <irenab> ajo: sound fine
14:14:48 <sc68cal> ajo: sounds good
14:14:51 <gsagie> sounds good to me
14:14:54 <ajo> thanks :)
14:14:59 <ajo> #topic Ideas for generic RPC mechanisms
14:15:11 <ajo> ok, this is still an inmature idea
14:15:22 <ajo> based on the ML feedback on the topic,
14:15:39 <ajo> we keep adding more RPC messages /calls from to/from agents with every new thing
14:15:54 <garyk> ajo: it may be too early to jump into implementation details if the api is still in discussion
14:15:58 <ajo> what if we were able to have a common interface to send updates on different types of objects
14:16:03 <ajo> garyk, you're probably right
14:16:23 <ajo> I just wanted to drop the idea to let others think about it and see if it makes some sense
14:16:26 <sc68cal> ajo: I think I see where you are going, I agree with garyk, it's big enough to warrant its own spec
14:16:27 <garyk> ajo: i think that it would also be a driver implementation detail
14:16:43 <ajo> sc68cal, that's right,
14:16:50 <sc68cal> ajo: but I see the merit in it, for sure!
14:17:26 <gsagie> ajo: are we considering using a no-agent approach or thats currently off topic?
14:17:43 <ajo> basically I was thinking of something similar to callbacks but via agents/rpc,
14:17:45 <ajo> but
14:17:53 <ajo> let's move on
14:17:55 <irenab> ajo:  would this be part of the ref impementation spec discussion?
14:18:22 <ajo> irenab, I guess if we propose such a thing, as sc68cal was saying it deserves it's own spec
14:18:26 <vikram__> ajo: can you share the details about ur idea
14:18:36 <ajo> but if we're going to add new rpc methods and calls... well.. may be it's a good moment
14:18:53 <ajo> vikram__, this is just the high level overview, didn't have more time to look at it
14:19:05 <irenab> just to undestand the way to proceed, we have API/Data Model spec, with no real backend implementation
14:19:15 <vikram__> ok
14:19:25 <sc68cal> just have to be careful about how many dependencies we insert before we start the actual work on QoS, otherwise we'll be in Zeta release ;)
14:19:40 <irenab> then there will be ref implementation spec (OVS based, I guess)
14:19:47 <vikram__> :-)
14:19:52 <ajo> sc68cal, I totally agree on that, I was just trying to address the concern of "we keep adding more rpc calls for every single feature" :)
14:20:10 <ajo> yes, I guess it's time to move onto that topic
14:20:10 <irenab> so you think there should be another spec? or just some work to be done related to one of these two specs?
14:20:29 <ajo> #topic inter-related specs which should happen after the API
14:20:36 <garyk> ajo: if this is bundeled in as part of a neutron port then we do not need additional calls. just the payload needs to change
14:20:52 <ajo> garyk, not exactly,
14:20:56 <garyk> why?
14:20:59 <ajo> garyk, this is similar to the security groups
14:21:01 <sc68cal> garyk: still need RPC for fetching policy stuff
14:21:12 <ajo> garyk, for example, if a policy is updated, we need the changes applied to the ports
14:21:16 <sc68cal> unless we're going to pack *more* data onto rabbitmq
14:21:20 <irenab> I thought we agreed not to talk about implementation details yet :-)
14:21:26 <ajo> '':D
14:21:37 <garyk> ok, now i understand. i was just thinking of the port creation :)
14:21:41 <ajo> ok, let's talk about implementation in the future :)
14:21:43 <ajo> irenab +1
14:22:03 <garyk> few dumb questions
14:22:04 <ajo> ok, specs we need for sure...
14:22:16 <ajo> ml2-ovs ml2-sriov, ml2-lb implementations
14:22:17 <garyk> will the api be in the neutron code base or an external project?
14:22:44 <ajo> garyk, that's still on debate,
14:22:54 <ajo> irenab, and sc68cal believe that's going to be faster,
14:23:07 <ajo> if we go the service-plugin way, that's probably an option
14:23:08 <garyk> as an external project?
14:23:22 <ajo> garyk, what do you think about the topic?
14:23:28 <irenab> similar to advanced services
14:23:36 <vikram__> +1
14:23:49 <ajo> garyk, my opinion is that it's something which should be available to all plugin implementors...
14:23:51 <sc68cal> Regardless - we're going to need a patch that adds an extension in neutron/extensions
14:23:53 <garyk> i feelt hat it is part of the core
14:23:59 <sc68cal> or a shim
14:24:00 <ajo> if it's well tested in coordination with neutron core stuff, I'm ok
14:24:11 <garyk> but being able to develop out of tree is certainly a lot faster
14:24:25 <garyk> the glue is what concerns me. i am not sure about the service hook
14:24:32 <ajo> garyk it's my feeling also that this is part of the core, as we're defining port & net properties
14:24:37 <garyk> that is more something that uses the ports etcs
14:24:46 <ajo> garyk, that's my feeling too
14:25:01 <garyk> i also think that the sec group model is very messy and in retrospect we should have done that differently
14:25:04 <ajo> garyk, but I'm not sure we have better mechanisms to decouple the code af this moment
14:25:09 <garyk> agree
14:25:22 <garyk> will there be a session at the summit so that maybe we can bash this through
14:25:23 <irenab> I think its more DB Mixin versus Service plugin discussion, not totally independent service discussion
14:25:31 <ajo> garyk, if we find a better way we can follow that path
14:25:42 <garyk> ok
14:26:19 <ajo> garyk, I'm still trying to understand the internals of neutron at this level so I'll be able to provide any beter idea, right now... I'm not able :D
14:26:20 <sadasu> this is an area where a design session at the summit could help?
14:26:38 <ajo> but I agree, it feels like it's not a service making use of ports, it's just the best way to decouple we have now
14:26:52 <ajo> sadasu. could be,
14:27:00 <irenab> ajo: +1
14:27:06 <sc68cal> ajo: I can teach you the ways of the force ;)
14:27:15 <ajo> we have a slot for QoS, but probably such topic would take a whole session :)
14:27:22 <ajo> mestery ^
14:27:25 <garyk> i am not familiar enough with the services to be able to have an opinion here. i just know that they create and delete ports.
14:27:30 <mestery> ajo: ++
14:27:48 <garyk> here we need to be part of the port creation (and update)
14:28:14 <sadasu> ajo: agree with your service dilemma
14:28:22 <ajo> I guess the idea with the service is to register for the port creation/update callbacks, being able to notify where necessary..
14:28:38 <irenab> sorry, have to leave. Will catch up later
14:28:53 <ajo> garyk, sadasu , please feel free to add ideas to the ML Thread bout the QoS service plugin or not  ;)
14:29:00 <ajo> bout->about :)
14:29:07 <ajo> ok, so
14:29:10 <ajo> about specs
14:29:27 <ajo> or devref's ;)
14:29:36 <sc68cal> ;)
14:29:44 <ajo> we may need to define how we're going to do it in the low level
14:29:48 <garyk> ajo: will do
14:29:52 <ajo> -ovs is clear to me
14:30:06 <ajo> I think moshele will take care of -sriov
14:30:08 <sadasu> ajo: will do, have a bit of catching up to do regarding what has happened in the ML
14:30:10 <ajo> anybody for -lb?
14:30:23 <garyk> what is -lb?
14:30:27 <ajo> linux bridge :)
14:30:39 <garyk> that is so 80's
14:30:45 <garyk> new black is ovn
14:30:55 <moshele> ajo: yes I will take sriov
14:30:57 <vikram__> i can take up
14:30:58 <ajo> :) yeah, but in previous iterations people had an interest on QoS/LB support :)
14:30:59 <garyk> then again retro is in
14:31:08 <ajo> garyk +1
14:31:10 <ajo> :D
14:32:04 <ajo> I guess, -OVN work will come later in time when they have a working implementation
14:32:09 <vikram__> ajo: linux bridge i can take up
14:32:16 <ajo> vikram__, that would be nice
14:32:39 <ajo> vikram__, I was planning to use ovs  queues with htb, which is what ovs supports
14:33:22 <ajo> not sure what was the plan for LB, or what's the best plan
14:33:35 <vikram__> ok. I used linux bridge long back need to refresh :D
14:33:36 <gsagie> you can leverage iptables for the rate limit
14:33:48 <gsagie> in linux bridge i believe
14:34:09 <ajo> I was planing to take on the -ovs low levels, but help is accepted
14:34:28 <ajo> talking of which... gsagie was proposing to try an agent-less approach to do the QoS
14:34:31 <ajo> via ovsdb interface
14:34:32 <vikram__> gsagie: +1
14:35:05 <gsagie> heh no comments sounds bad... ;)
14:35:14 <ajo> :-)
14:35:28 <ajo> gsagie, I believe it's better if we have the same approach in the different levels instead of mixing :)
14:35:31 * sc68cal hopes he can assist ajo on the ovs low levels
14:35:42 <vikram__> agent-less? what's that..
14:35:56 <ajo> also it would require good coordination with the current ovs-agent :)
14:36:18 <gsagie> ajo: not sure what you mean different levels, i believe some backends will implement this agentless as well
14:36:19 <ajo> gsagie, may be it's where OVN is going to do better than the current ovs implementation :)
14:36:43 <ajo> true gsagie , but I mean, for ml2-ovs we would be mixing
14:36:54 <ajo> for ml2-ovn, probably that's the way to go
14:37:01 <gsagie> np
14:37:37 <ajo> vikram__, agentless means you control the ovsdb + openflow rules from your neutron-server
14:37:52 <ajo> instead of sending rpc commands to an agent
14:37:55 <vikram__> ok
14:38:02 <gsagie> i can probably provide help as well for the ovs and maybe also the linux bridge if needed
14:38:02 <ajo> gsagie, am I correct?
14:38:27 <ajo> gsagie, thanks a lot
14:38:42 <gsagie> i havent looked at the QoS settings, but i believe its only with OVSDB, but yeah thats the concept
14:39:02 <ajo> gsagie, it could involve some rules if we want to control ingress too
14:39:22 <ajo> for egres it's just attaching a queue to the port
14:39:52 <ajo> and of course, it requires some rules to do the same with different types of traffic
14:40:02 <ajo> ok, to sumarize
14:40:33 <ajo> #action vikram__ will take care of the ml2-linuxbridge implementation
14:40:52 <ajo> #action moshele will take care of the ml2-sriov implementation
14:41:24 <ajo> #action ajo will take care of the ml2-ovs implementation, gsagie and sc68cal offer help
14:41:40 <ajo> also gsagie you offered help to vikram__ regarding linux bridge
14:41:41 <vikram__> What all QoSPolicy we will be implementing at the first go now?
14:41:52 <ajo> ratecontrol
14:41:59 <ajo> but, with the new more open RFE process
14:42:09 <ajo> we could propose other types as we finish ratecontrol
14:42:23 <vikram__> ok
14:42:24 <ajo> I hope that goes forward ;) mestery++
14:43:06 <ajo> ok , we had a conflicting proposal so far (But this is looking into the future of supported types)
14:43:22 <ajo> I'd like to comment now at least, since we have time
14:43:29 <ajo> #topic conflicting type proposals
14:43:48 <ajo> vikram__, I believe it was you, who proposed to use IPv6 flow labels to put QoS levels, right?
14:43:55 <vikram__> yes
14:44:04 <ajo> there's some RFC about using IPv6 flow labels for QoS, do you have the reference?
14:44:38 <ajo> There are other RFCs proposing ot use the flow labels for tenant isolation in virtual networks
14:44:39 <vikram__> i have can send after the meeting
14:44:55 <ajo> ianwells was proposing that ... let me look for it
14:46:00 <vikram__> https://www.ietf.org/rfc/rfc3697.txt
14:46:46 <ajo> #link https://etherpad.openstack.org/p/IPv6Networks
14:46:48 <sc68cal> yes but he was using them for tenant isolation
14:46:52 <ajo> #link https://www.ietf.org/rfc/rfc3697.txt
14:47:08 <ajo> #link https://tools.ietf.org/html/rfc6437
14:47:22 <sc68cal> My concern about using packet headers is contention over how they are used, and if we are adding new meanings
14:47:22 <ajo> correct sc68cal , this is why I think it's conflicting
14:47:39 <vikram__> yes
14:47:54 <ajo> yes, I think we can decide at a later time,
14:48:01 <ajo> based on the status of the different RFCs
14:48:25 <ajo> I just wanted to raise the issue so you're able to discuss with the right people
14:48:47 <ajo> vikram__, if you'll be able to come to the Summit, I can put you in contact with Ian
14:49:02 <ajo> #topic free discussion
14:49:02 <vikram__> Thanks. I am travelling
14:49:15 <ajo> ok, something important you believe we should talk about?
14:49:27 <ajo> or ideas for the next agenda?
14:49:39 <vikram__> how about packet priority marking and ecn
14:49:52 <ajo> vikram__, I believe we can discuss those in the future
14:49:56 <ajo> when we have the basic building blocks
14:50:00 <ajo> it's written in the current spec
14:50:03 <ajo> as future ideas
14:52:05 <ajo> A comment I had from irena as to standarize the parameters dict in command line
14:52:14 <ajo> as some other cmdline commands do
14:52:22 <ajo> I need to look into that
14:52:46 <ajo> ah, and I was thinking
14:52:55 <ajo> if it made sense to have a low level "qos_driver"
14:53:03 <ajo> as we have for the "firewall_driver" in security groups
14:53:23 <ajo> sc68cal, what do you think about such thing ?
14:53:47 <ajo> for example, in the OVSHybrid thing, we could use lb or ovs to do QoS
14:53:57 <ajo> so.. having some sort of modular driver would help there
14:54:05 <sc68cal> ajo: yeah my old code had a abstract driver class, that the dscp driver inherited from
14:54:08 <ajo> if one works better than the other, people just switch
14:54:46 <ajo> sc68cal, ok, that sounds like we thought the same way
14:55:05 <sc68cal> ajo: https://github.com/netoisstools/neutron/tree/comcast_milestone_proposed/neutron/services/qos/drivers
14:55:41 <ajo> sc68cal, exactly
14:56:02 <ajo> #link https://github.com/netoisstools/neutron/tree/comcast_milestone_proposed/neutron/services/qos/drivers
14:56:15 <ajo> this way, if this is finally developed as a service, we can keep the drive implementation at the same place
14:56:25 <ajo> and extend the agent in a modular way
14:56:31 <ajo> via the same interface
14:56:56 <ajo> ok, anything else, or shall we end meeting? :)
14:57:52 <ajo> #endmeeting