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