15:00:42 <ralonsoh> #startmeeting neutron_qos
15:00:43 <openstack> Meeting started Tue Jun 20 15:00:42 2017 UTC and is due to finish in 60 minutes.  The chair is ralonsoh. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:00:44 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:46 <openstack> The meeting name has been set to 'neutron_qos'
15:00:47 <ralonsoh> Hello
15:00:50 <mlavalle> o/
15:00:56 <ralonsoh> hi mlavalle
15:00:57 <davidsha> Hi
15:00:58 <alisanhaji> Hello
15:01:06 <ralonsoh> hi davidsha, alisanhaji
15:01:26 <ralonsoh> slawek is not going to attend today, but I have his updates
15:01:37 <davidsha> kk
15:01:43 <reedip_> o/
15:01:49 <ralonsoh> hi reedip_
15:01:52 <ralonsoh> let's start
15:01:54 <ralonsoh> #topic RFEs
15:02:17 <ralonsoh> QoS, in general, has been a bit slow during last weeks
15:02:33 <ralonsoh> slaweq is the most active contributor right now
15:02:40 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1692951
15:02:41 <openstack> Launchpad bug 1692951 in neutron "[RFE] DSCP mark on the outer header" [Wishlist,Confirmed]
15:02:55 <ralonsoh> This is a new possible RFE
15:03:18 <ralonsoh> it makes sense: currently there is no marking in tunneling headers
15:03:21 <alisanhaji> Yes, I filled it
15:03:41 <ralonsoh> alisanhaji: perfect. Do you have plans to implement it?
15:03:49 <davidsha> We could just extend the existing dscp rule with a new field.
15:03:54 <ralonsoh> alisanhaji: OVS or LB drivers
15:04:12 <alisanhaji> Well I can but we can discuss the possible implementation
15:04:15 <ralonsoh> davidsha: hmmmm also you should be able to copy the inner one
15:04:15 <alisanhaji> Both I think
15:04:49 <ralonsoh> mlavalle: you have more experience in this. Do you think that should need an spec??
15:05:02 <mlavalle> ralonsoh: I think it will
15:05:18 <mlavalle> but before that, has the rfe been discussed int the drivers meeting?
15:05:23 <davidsha> alisanhaji: Do you intend to have a separate dscp mark for each?
15:05:34 <alisanhaji> the solution is to use the MARK field to track the inner header and mark the outer header
15:05:35 <davidsha> mlavalle: Not ye I believe
15:06:11 <mlavalle> so the steps should be to have the rfe approved in the drivers meeting and then we can discuss the spec
15:06:14 <alisanhaji> we could just copy the inner DSCP but to have extended possibilities, I think we should separate both
15:07:05 <ralonsoh> alisanhaji: please, join http://eavesdrop.openstack.org/#Neutron_drivers_Meeting to discuss it
15:07:11 <mlavalle> if this team has a strong feeling that this should be implemented, I will take a look at the filed bug and mark it as triaged, so it gets discussed by the drivers
15:07:16 <davidsha> alisanhaji: kk, It probably won't need a seperate QoS rule, just add a new optional field for encap_mark or such.
15:07:19 <ralonsoh> alisanhaji: IMO, it makes sense
15:07:41 <mlavalle> ralonsoh: ^^^^
15:08:14 <ralonsoh> mlavalle: I agree
15:08:19 <mlavalle> ok
15:08:49 <ralonsoh> perfect, next one
15:08:53 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1578989
15:08:54 <openstack> Launchpad bug 1578989 in neutron "[RFE] Strict minimum bandwidth support (egress)" [Wishlist,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
15:08:56 <mlavalle> the question the drivers have been asking about QoS RFE's is whether you are interested in the feature and whether you have resources to implement
15:09:25 <ralonsoh> mlavalle: this about this spec?
15:09:33 <ralonsoh> mlavalle: the strict min?
15:09:36 <davidsha> ralonsoh: in general.
15:09:42 <mlavalle> the comment was for the previous one
15:09:49 <mlavalle> and in general
15:10:14 <ralonsoh> in general: we are just two or three people implementing the features
15:10:16 <mlavalle> if we can answer yes to both questions, drivers will support
15:10:44 <ralonsoh> mlavalle: I can help/implement the DSCP mark RFE
15:10:51 <ralonsoh> mlavalle: so yes
15:11:05 <mlavalle> great
15:11:30 <ralonsoh> mlavalle: thanks
15:11:50 <ralonsoh> mlavalle: what about the strict min one?
15:11:51 <davidsha> I can review also.
15:12:03 <ralonsoh> mlavalle: because the spec is merged
15:12:26 <mlavalle> ralonsoh: with that one, I think we can move ahead
15:12:32 <ralonsoh> but the main contributor and parent of the idea, ajo, is not working in the team anymore
15:13:05 <mlavalle> I understand slaweq__ wanted to do some pieces, right?
15:13:26 <ralonsoh> mlavalle: I mean, I really don't know exactly which was the whole idea, who to implement it
15:13:49 <ralonsoh> mlavalle: I think ajo and me had different ideas about it...
15:13:55 <mlavalle> ahhhh
15:14:01 <mlavalle> I didn't realize that
15:14:12 <ralonsoh> mlavalle: that's the point
15:14:27 <mlavalle> we could amend the spec
15:14:55 <ralonsoh> mlavalle: ok, I'll try to ping ajo. Do you think this is a good idea?
15:14:56 <mlavalle> you are here and if you have a clear concept of wht should be implemented, we can pursue that
15:15:03 <mlavalle> I do
15:15:08 <ralonsoh> mlavalle: perfect
15:15:42 <ralonsoh> ok, let's move to the next one
15:15:45 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1596611
15:15:47 <openstack> Launchpad bug 1596611 in neutron "[RFE] Create L3 IPs with qos (rate limit)" [Wishlist,Triaged] - Assigned to LIU Yulong (dragon889)
15:15:52 <ralonsoh> The spec is merged
15:16:06 <ralonsoh> but there is no activity on the API and the LB implementation
15:16:44 <ralonsoh> I tried to ping the author with no luck
15:17:12 <ralonsoh> I'll comment again the patches, just to know if he is going to continue the development
15:17:24 <mlavalle> yeah, let's do that
15:17:42 <ralonsoh> perfect, next one
15:17:43 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1560961:
15:17:45 <openstack> Launchpad bug 1560961 in neutron "[RFE] Allow instance-ingress bandwidth limiting" [Wishlist,Fix released] - Assigned to Slawek Kaplonski (slaweq)
15:17:54 <ralonsoh> good progress: spec and OVS implementation merged
15:17:59 <mlavalle> yeap
15:18:05 <ralonsoh> LB implementation: #link https://review.openstack.org/#/c/475584/
15:18:13 <mlavalle> after some API turbulence LOL
15:18:15 <ralonsoh> waiting for reviews!
15:18:27 <mlavalle> I'll add that to my pile
15:18:35 <ralonsoh> mlavalle: hehehe but everything could be solved!!
15:18:44 <ralonsoh> mlavalle: thanks!!
15:18:55 <ralonsoh> slaweq is doing a very good job
15:19:04 <mlavalle> yeah, he is great
15:19:09 <mlavalle> keep him happy
15:19:14 <ralonsoh> sure!!!
15:19:38 <ralonsoh> ok, next topic (I think I'm not missing anything)
15:19:39 <ralonsoh> #topic Bugs
15:19:49 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1698046
15:19:50 <openstack> Launchpad bug 1698046 in neutron " Add support for ingress bandwidth limit rules in ovs agent" [High,Confirmed]
15:19:58 <ralonsoh> I'll take this one
15:20:04 <ralonsoh> Is just the documentation
15:20:15 <ralonsoh> for ingress rules
15:20:33 <ralonsoh> next one
15:20:34 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1697937
15:20:36 <openstack> Launchpad bug 1697937 in neutron "TC shouldn't raise an exception when deleting qdisc if device doesn't exist" [High,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
15:20:40 <mlavalle> correct
15:20:44 <mlavalle> only doc
15:20:52 <ralonsoh> that was a bug requested by kevin
15:21:15 <ralonsoh> the patch: https://review.openstack.org/#/c/474244/
15:21:23 <ralonsoh> is waiting for last reviews
15:21:47 <mlavalle> I'll look at this one today
15:22:03 <ralonsoh> next one
15:22:05 <ralonsoh> https://bugs.launchpad.net/neutron/+bug/1676877
15:22:07 <openstack> Launchpad bug 1676877 in neutron "Increase "TestQosPlugin.test_update_policy_rule" coverage" [Medium,In progress] - Assigned to Reedip (reedip-banerjee)
15:22:15 <ralonsoh> reedip_: how is going the patch?
15:22:22 <ralonsoh> https://review.openstack.org/#/c/456773/
15:22:28 <reedip_> havent had the time to relook at it . Will do it after the meeting.
15:22:42 <ralonsoh> reedip_: thanks! I'll keep an eye on this one
15:23:07 <ralonsoh> next one
15:23:08 <ralonsoh> https://bugs.launchpad.net/neutron/+bug/1649517
15:23:10 <openstack> Launchpad bug 1649517 in neutron "qos policy attached to network, qos_policy_id is reflecting on neutron net-show , but not on the port with neutron port-show" [Wishlist,In progress] - Assigned to Reedip (reedip-banerjee)
15:23:11 <reedip_> ralonsoh : just saw I already had an edit ready . Just pushed it
15:23:25 <ralonsoh> this one is yours too
15:23:34 <ralonsoh> https://review.openstack.org/#/c/419642/
15:23:54 <reedip_> ralonsoh : Just pushed a patch a minute ago
15:23:56 <reedip_> :)
15:24:17 <ralonsoh> now I see that! so I'll review it after the meeting, perfect!
15:24:34 <ralonsoh> and the last one
15:24:38 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1694396
15:24:39 <openstack> Launchpad bug 1694396 in neutron " qos scenario tests should be skipped if rule type is not supported" [High,In progress] - Assigned to YAMAMOTO Takashi (yamamoto)
15:24:52 <ralonsoh> yamamoto in not here.....
15:24:58 <ralonsoh> what a pity
15:25:23 <mlavalle> it makes sense, though
15:25:28 <mlavalle> I mean the bug
15:25:43 <davidsha> He went offline about 10 mins ago.
15:25:54 <ralonsoh> I know
15:26:04 <ralonsoh> but only one project is using it
15:26:13 <reedip_> its 0030 there in Japan :|
15:26:18 <ralonsoh> I know that backwards compatibility should prevail
15:26:57 <ralonsoh> but IMO this change (https://review.openstack.org/#/c/461257/) should be merged and the project affected should modify the code
15:27:28 <ralonsoh> following the logic of not braking anything, there will be no new features
15:27:38 <ralonsoh> s/braking/breaking
15:28:06 <ralonsoh> but, of course, comments are accepted in the patch https://review.openstack.org/#/c/468982/
15:28:35 <ralonsoh> to discuss if it makes sense to revert the patch or to modify the tests in the external project
15:29:05 <ralonsoh> mlavalle: if you don't mind, please take a look at https://review.openstack.org/#/c/468982/
15:29:34 <ralonsoh> ok, that's all the backlog I have
15:29:43 <ralonsoh> #topic Open Discussion
15:30:03 <ralonsoh> do have any open?
15:30:19 <reedip_> ralonsoh : I was just thinking , and its just a simple point. do we ever consider MPTCP as a protocol for DCNs in Neutron?
15:30:56 <reedip_> I havent explored it in Neutron, and was thinking if it can help DCNs ?
15:30:57 <ralonsoh> reedip_: uffff no.
15:31:07 <reedip_> :)
15:31:30 <reedip_> okk, the uffff means you have had this thought a lot
15:31:41 <ralonsoh> reedip_: do you have any doc to illustrate us?
15:32:00 <ralonsoh> no no the uffff means: if we put this in Neutron, it will explode
15:32:07 <ralonsoh> hehehe
15:32:32 <mlavalle> lol
15:32:38 <davidsha> Explosions are nice to watch though...
15:32:43 <ralonsoh> hahahaha
15:33:03 <reedip_> ralonsoh : I was looking at XMP protocol ( a white paper ) and it had a mention of MPTCP . More about it here https://www.multipath-tcp.org/
15:33:09 <ralonsoh> reedip_: if you have something like an spec, doc or something else, please share it
15:33:16 <reedip_> no I dont want the wrath of Neutron Cores on my head !
15:34:00 <ralonsoh> btw, ECN?
15:34:02 <reedip_> It is basically multipath TCP which tries to use multiple paths to a destination  to reduce the overall load and improve the throughput
15:34:17 <reedip_> ralonsoh : I was working on the ECN only , it just branched from there
15:34:19 <davidsha> reedip_: Sounds like it could be a candidate for a l3 extension all to itself.
15:34:27 <ralonsoh> but this will improve the speed in the host?
15:34:31 <ralonsoh> I don't think so
15:34:49 <reedip_> ralonsoh : it is useful for bulk data transfer like VM Migration
15:35:00 <ralonsoh> must MPTCP be supported by TOR?
15:35:01 <reedip_> or large chunks of data trasnfer
15:35:31 <reedip_> it is not useful for low -latency transfers which is there for Hadoop , Map-reduce or cassadra
15:35:42 <reedip_> anyways, just my thought.
15:36:02 <reedip_> davidsha: let me first get ECN out of the way :) then I will think about MPTCP :P
15:36:12 <davidsha> reedip_: :P
15:36:14 <ralonsoh> reedip_: agree!!
15:36:18 <ralonsoh> hehehehe
15:36:20 <reedip_> anyways, I got to go
15:36:26 <ralonsoh> no problem
15:36:29 <ralonsoh> any other open??
15:36:32 <davidsha> reedip_: cya!
15:36:38 <reedip_> thanks , cya later guys :)
15:36:42 <davidsha> I'm good.
15:36:43 <mlavalle> o/
15:36:53 <ralonsoh> thank you guys!!
15:37:03 <ralonsoh> bye!
15:37:05 <ralonsoh> #endmeeting