15:00:18 <ralonsoh> #startmeeting neutron_qos
15:00:19 <openstack> Meeting started Tue Sep 26 15:00:18 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:21 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
15:00:22 <ralonsoh> Hello
15:00:23 <openstack> The meeting name has been set to 'neutron_qos'
15:00:44 <mlavalle> o/
15:00:59 <davidsha> Hi
15:01:08 <ralonsoh> reedip and slaweq will be here soon
15:01:27 <ralonsoh> ok, let's start
15:01:28 <ralonsoh> #topic RFEs
15:01:42 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1505627
15:01:43 <openstack> Launchpad bug 1505627 in neutron "[RFE] QoS Explicit Congestion Notification (ECN) Support" [Wishlist,Triaged] - Assigned to Reedip (reedip-banerjee)
15:02:02 <ralonsoh> The spec review is going well
15:02:05 <ralonsoh> #link https://review.openstack.org/#/c/445762/
15:02:05 <patchbot> patch 445762 - neutron-specs - Spec for Explicit Congestion Notification
15:02:30 <ralonsoh> But I think reedip needs to address those late comments
15:03:05 <ralonsoh> Let's take this one out if reedip is not here now
15:03:09 <ralonsoh> next one
15:03:11 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1692951
15:03:12 <openstack> Launchpad bug 1692951 in neutron "[RFE] DSCP mark on the outer header" [Wishlist,Confirmed] - Assigned to Ali Sanhaji (ali-sanhaji)
15:03:26 <ralonsoh> The RFE is not approved yet
15:03:32 <ralonsoh> but there are two patches
15:03:36 <ralonsoh> #link https://review.openstack.org/#/c/501267/
15:03:37 <patchbot> patch 501267 - neutron - Adding TOS mark in OVS tunnels outer headers
15:03:43 <ralonsoh> #link https://review.openstack.org/#/c/501271/
15:03:43 <patchbot> patch 501271 - neutron - Make TOS inherit possible in LB
15:04:05 <mlavalle> ralonsoh: it is approved
15:04:10 <ralonsoh> oooook
15:04:13 <ralonsoh> I think see that
15:04:21 <mlavalle> we discussed it in the last drivers meeting before the ptg
15:04:30 <ralonsoh> perfect
15:04:47 <mlavalle> and Ali did a great job presenting it
15:04:51 <ralonsoh> I need to take a look again to both patches, but both are in progress
15:04:59 <ralonsoh> That's perfect
15:05:07 <ralonsoh> He ping me the week before
15:05:39 <mlavalle> let's just keep this in mind: https://bugs.launchpad.net/neutron/+bug/1692951/comments/3
15:05:40 <openstack> Launchpad bug 1692951 in neutron "[RFE] DSCP mark on the outer header" [Wishlist,Confirmed] - Assigned to Ali Sanhaji (ali-sanhaji)
15:06:24 <ralonsoh> I remember reading this part, but not "is approved"
15:06:41 <mlavalle> lol, that was the most important part
15:06:51 <ralonsoh> ok, so let's take time to review the patches. I don't see any big data change at all
15:07:22 <ralonsoh> mlavalle: I know....
15:07:43 <ralonsoh> ok, next one
15:07:44 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1649517
15:07:46 <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:07:56 <ralonsoh> The code is almost ready
15:07:59 <ralonsoh> #link https://review.openstack.org/#/c/419642/
15:07:59 <patchbot> patch 419642 - neutron - Add network_qos_policy_id to port info
15:08:37 <mlavalle> is the failure caused by the change in the patch
15:08:38 <ralonsoh> But reedip needs to finish and address the latest comments
15:08:39 <mlavalle> ?
15:08:54 <mlavalle> ok, so I should expect a follow up patch
15:09:17 <ralonsoh> the functional test fail is not related, IMO
15:09:28 <ralonsoh> but there should be another patch
15:09:34 <mlavalle> ok
15:09:54 <ralonsoh> next one
15:09:56 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1596611
15:09:57 <openstack> Launchpad bug 1596611 in neutron "[RFE] Create L3 IPs with qos (rate limit)" [Wishlist,Triaged] - Assigned to LIU Yulong (dragon889)
15:10:11 <ralonsoh> There are two patches in gerrit
15:10:27 <ralonsoh> one sec
15:10:49 <slaweq_> hello
15:10:50 <ralonsoh> Well, one of them was abandoned
15:10:51 <slaweq_> sorry for late
15:10:56 <ralonsoh> #link https://review.openstack.org/#/c/445762/
15:10:56 <patchbot> patch 445762 - neutron-specs - Spec for Explicit Congestion Notification
15:11:13 <ralonsoh> sorry, not this one
15:11:18 <mlavalle> yeah, I saw that.
15:11:30 <mlavalle> but is this something we still want to pursue?
15:11:30 <ralonsoh> #link https://review.openstack.org/#/c/453458/
15:11:31 <patchbot> patch 453458 - neutron - [L3][QoS] Adding L3 rate limit TC lib
15:11:33 <ralonsoh> This one
15:11:51 <ralonsoh> Is still under review, but stopped since august
15:12:14 <ralonsoh> mlavalle: It's interesting but, personally, I don't have time for this
15:12:16 <mlavalle> would a review help to nudge it forward?
15:12:36 <ralonsoh> mlavalle: I tried to ping the author with no luck
15:12:59 <mlavalle> ok, I'll go through it
15:13:07 <ralonsoh> mlavalle: I don't know if just a review is enough. We should know if the author is going to continue
15:13:14 <slaweq_> ralonsoh: it's this one with another tc class, right?
15:13:21 <ralonsoh> yes
15:13:21 <mlavalle> yes
15:13:27 <slaweq_> ok
15:13:39 <ralonsoh> The implementation is correct, but I don't agree with splitting the TC library
15:13:59 <mlavalle> would you leave a comment there?
15:14:01 <slaweq_> IIRC it was waiting for some core reviewers as me and ralonsoh don't agree with way how author did it
15:14:08 <ralonsoh> Sure, several times
15:14:17 <mlavalle> ok
15:14:22 <mlavalle> then I'll chime in
15:14:27 <ralonsoh> mlavalle: thanks
15:14:49 <ralonsoh> and the last RFE
15:14:52 <mlavalle> and ask for help if I get myself in trouble, as I frequently do ;-)
15:15:04 <ralonsoh> mlavalle: yes, that's the point
15:15:28 <ralonsoh> ok, next RFE
15:15:30 <ralonsoh> #link https://bugs.launchpad.net/neutron/+bug/1560963
15:15:31 <openstack> Launchpad bug 1560963 in neutron "[RFE] Minimum bandwidth support (egress)" [Wishlist,In progress] - Assigned to Rodolfo Alonso (rodolfo-alonso-hernandez)
15:15:44 <ralonsoh> I abandoned this RFE for several months
15:15:53 <ralonsoh> But I'm going to retake the work
15:15:55 * mlavalle did the same ;-(
15:16:08 <ralonsoh> mlavalle: I have some questions for you, about placement
15:16:27 <ralonsoh> mlavalle: do you have time for a conversation about this? whenever you want
15:16:32 <ralonsoh> I have some ideas
15:16:56 <mlavalle> do you want to discuss this outside the meeting?
15:17:04 <ralonsoh> I think it's going to take a bit of time
15:17:16 <ralonsoh> and I can put the conclusions in a mail
15:17:21 <ralonsoh> and in the RFE
15:17:23 <mlavalle> I am very interested in this, so yeah, I will make time
15:17:28 <ralonsoh> perfect!!
15:17:41 <ralonsoh> there are no more topics in the etherpad
15:17:43 <mlavalle> we are targeting this for Queens, right?
15:18:03 <ralonsoh> mlavalle: yes... if the placement API is ready and Nova side
15:18:14 <ralonsoh> mlavalle: I'm currently working in the Nova side too
15:18:29 <mlavalle> jaypipes said he was hoping to get it ready in Q-1
15:18:34 <mlavalle> during the PTG
15:18:48 <ralonsoh> I know, sean-k-mooney told me that
15:19:02 <mlavalle> I even included the comment in the Neutron PTG summary that sent a couple of days ago to the ML
15:19:14 <ralonsoh> mlavalle: I saw that
15:19:29 <mlavalle> so I guess it is a matter of tracking it down
15:19:38 <mlavalle> but we should start working now
15:19:42 <mlavalle> in parallel
15:19:49 <mlavalle> in my opinion
15:19:58 <ralonsoh> mlavalle: perfect! so we can talk later today
15:20:19 <mlavalle> it won't be the first time I write code against an unfinished placement API :-)
15:20:56 <ralonsoh> mlavalle: hehehe. BTW, I have plans to move your client to a common place
15:20:56 <mlavalle> what time is it now for you?
15:21:01 <ralonsoh> 1620
15:21:17 <mlavalle> would 1800 be too late for you?
15:21:22 <ralonsoh> not at all
15:21:30 <mlavalle> ok, I'll ping you then
15:21:35 <ralonsoh> perfect!
15:21:48 <ralonsoh> I don't have any other RFE in etherpad
15:21:55 <ralonsoh> Am I missing something?
15:22:05 <mlavalle> ralonsoh: and yes, I was fully expecting that client to be moved and changed a lot ;-)
15:22:19 <ralonsoh> sure hehehe
15:22:35 <Fouad_Benamrane> Hi all,
15:23:06 <Fouad_Benamrane> I want to discuss my RFE with you guys.
15:23:17 <Fouad_Benamrane> #link https://bugs.launchpad.net/neutron/+bug/1708460
15:23:19 <openstack> Launchpad bug 1708460 in neutron " [RFE] Reaction to network congestion for qos" [Undecided,Invalid]
15:23:19 <ralonsoh> Fouad_Benamrane: please, go on
15:23:41 <ralonsoh> it's an invalid one, there is another similar
15:23:43 <Fouad_Benamrane> Why it's marked as invalid by reedip
15:23:46 <ralonsoh> ECN, by reedup
15:23:50 * mlavalle will be away from keyboard a few minutes
15:23:51 <ralonsoh> one sec
15:23:56 <Fouad_Benamrane> It's not the same.
15:24:29 <Fouad_Benamrane> Here we try to add ECN capability to neutron through ovs rules.
15:24:50 <Fouad_Benamrane> And also we react dynamically to it.
15:25:15 <Fouad_Benamrane> By policing hosts that generate congestion.
15:25:44 <Fouad_Benamrane> Our solution does not depend on host at all
15:25:46 <ralonsoh> Fouad_Benamrane: I don't see where are you talking about OVS
15:25:50 <ralonsoh> in the RFE
15:26:27 <ralonsoh> anyway, the RFE is very similar
15:27:01 <Fouad_Benamrane> Reedip RFE propose to use L3 router instead
15:27:04 <ralonsoh> IMO, this "extra" you are adding (creating a QOS limit rule), could be added to reedip's RFE
15:27:48 <Fouad_Benamrane> Ok, we can combine our REF,
15:27:59 <Fouad_Benamrane> Why not.
15:28:30 <davidsha> It could involve integrating the bandwidth limit rule with CCF as well for the policing rather than including it all in the ecn rule.
15:28:35 <ralonsoh> Fouad_Benamrane: let me take a look at both RFE and reedip SPEC
15:28:51 <Fouad_Benamrane> OK
15:29:05 <ralonsoh> davidsha: could you explain it again?
15:29:19 * mlavalle is back
15:29:51 <ralonsoh> davidsha: ?
15:30:03 <davidsha> ralonsoh: Rather than having a specific policing inside the new ecn rule a general one could be made by extending the bandwidth limit rule to work with the Common Classification framework
15:30:35 <ralonsoh> ok, but is the CCF ready to be used?
15:30:37 <Fouad_Benamrane> But the bandwidth limit rule is static
15:30:55 <Fouad_Benamrane> We need to keep track of congestion source and react to it.
15:31:07 <davidsha> ralonsoh: at the moment, no, not yet.
15:31:40 <ralonsoh> Fouad_Benamrane: can you explain your proposal in a SPEC?
15:31:49 <Fouad_Benamrane> Yes,
15:31:59 <ralonsoh> Fouad_Benamrane: perfect!
15:32:11 <davidsha> Fouad_Benamrane: If I'm not mistaken, if there is congestion the ecn value is changed to "11" isn't it?
15:32:13 <ralonsoh> Fouad_Benamrane: BTW, you are planning to support only OVS
15:32:42 <Fouad_Benamrane> Yes, this done by ECN switch in the middle of the network.
15:34:17 <ralonsoh> Fouad_Benamrane: ok, I'll mark your RFE as new again. This should not be invalid for now
15:34:46 <Fouad_Benamrane> Ok, so after that I have to propose a new spec, is it right ?
15:35:17 <ralonsoh> Fouad_Benamrane: please, take a look at https://review.openstack.org/#/c/445762/
15:35:18 <patchbot> patch 445762 - neutron-specs - Spec for Explicit Congestion Notification
15:35:21 <davidsha> Fouad_Benamrane: I'd say sync with reedip first.
15:35:31 <ralonsoh> Do you think your proposal could be integrated here?
15:35:58 <Fouad_Benamrane> ok, I will.
15:36:04 <mlavalle> ralonsoh, Fouad_Benamrane: I'll mark the RFE as triaged and indicate that we are waitring for a spec
15:36:18 <mlavalle> makes sense?
15:36:32 <ralonsoh> mlavalle: as davidsha said, reedip and Fouad_Benamrane should talk first to merge both
15:36:35 <ralonsoh> if possible
15:36:42 <mlavalle> ah, ok
15:36:47 <mlavalle> I missed that
15:37:19 * mlavalle being tormented by a rain of messages from somewhere else :-(
15:37:26 <ralonsoh> hehehe
15:37:33 <ralonsoh> ok, any other topic??
15:37:56 <davidsha> I'm good.
15:38:00 <ralonsoh> let's move to next one
15:38:01 <ralonsoh> #topic Bugs
15:38:19 <ralonsoh> there are no bugs in the list
15:38:26 <slaweq_> \o/
15:38:38 <ralonsoh> slaweq_: yes?
15:38:49 <slaweq_> I'm just happy that there are no bugs :)
15:38:54 <ralonsoh> ahhh hehhehehe
15:38:55 <ralonsoh> sorry
15:38:57 <mlavalle> me too
15:39:04 <mlavalle> \o/
15:39:10 <ralonsoh> perfect, next topic
15:39:11 <ralonsoh> #topic Other Changes
15:39:21 <ralonsoh> and general discussion
15:39:40 <ralonsoh> Do you have somthing in your agenda?
15:40:19 <ralonsoh> ok, thank you very much guys!
15:40:25 <mlavalle> o/
15:40:27 <slaweq_> thx
15:40:29 <ralonsoh> #endmeeting