network and vnic qos

Sun Jul 14 09:23:38 UTC 2013

----- Original Message -----
| From: "Doron Fediuck" <dfediuck at redhat.com>
| To: "Giuseppe Vallarelli" <gvallare at redhat.com>
| Cc: "Ofri Masad" <omasad at redhat.com>, arch at ovirt.org, "Moti Asayag" <masayag at redhat.com>, "Mike Kolesnik"
| <mkolesni at redhat.com>, "Michal Privoznik" <mprivozn at redhat.com>
| Sent: Sunday, July 14, 2013 11:16:02 AM
| Subject: Re: network and vnic qos
| 
| 
| 
| ----- Original Message -----
| | From: "Giuseppe Vallarelli" <gvallare at redhat.com>
| | To: "Ofri Masad" <omasad at redhat.com>
| | Cc: arch at ovirt.org, "Moti Asayag" <masayag at redhat.com>, "Mike Kolesnik"
| | <mkolesni at redhat.com>, "Michal Privoznik"
| | <mprivozn at redhat.com>, "Doron Fediuck" <dfediuck at redhat.com>
| | Sent: Sunday, July 14, 2013 11:36:45 AM
| | Subject: Re: network and vnic qos
| | 
| | ----- Original Message -----
| | | From: "Ofri Masad" <omasad at redhat.com>
| | | To: "Giuseppe Vallarelli" <gvallare at redhat.com>
| | | Cc: arch at ovirt.org, "Moti Asayag" <masayag at redhat.com>, "Mike Kolesnik"
| | | <mkolesni at redhat.com>, "Michal Privoznik"
| | | <mprivozn at redhat.com>, "Doron Fediuck" <dfediuck at redhat.com>
| | | Sent: Sunday, July 14, 2013 9:22:16 AM
| | | Subject: Re: network and vnic qos
| | | 
| | | Hi Giuseppe,
| | 
| | Hi Ofri,
| | 
| | | First of all, thanks for reviewing the design and the implementation.
| | | as for your comments, as I see it, we need to separate between what we
| | | can
| | | do
| | | (using libvirt) and what we would like to expose to the user.
| | | in my point of view, when a user is working with out engine (in appose to
| | | working directly with libvirt or vdsm) he expects different things.
| | | this is why we sometime take different choices from libvirt, to make the
| | | usage more simple/intuitive, to allow more complex abstraction
| | | or to get better control over the full system.
| | 
| | I understand the need of taking different decisions or not being completely
| | tied to the underlying implementation. What I feel is that libvirt is much
| | more flexible and we're limiting the usage. If you feel this the right way
| | to
| | go it's perfectly fine to me. In case users will have different
| | expectations
| | than we might revise this decision in the future.
| | 
| | | 
| | | specific comment inline
| | |      
| | | ----- Original Message -----
| | | > From: "Giuseppe Vallarelli" <gvallare at redhat.com>
| | | > To: arch at ovirt.org
| | | > Cc: "Ofri Masad" <omasad at redhat.com>, "Moti Asayag"
| | | > <masayag at redhat.com>,
| | | > "Mike Kolesnik" <mkolesni at redhat.com>,
| | | > "Michal Privoznik" <mprivozn at redhat.com>
| | | > Sent: Thursday, July 11, 2013 6:14:59 PM
| | | > Subject: network and vnic qos
| | | > 
| | | > Hi Ofri, me, Moti and Mike have been looking carefully through the
| | | > design
| | | > spec of the vnic profiles[0]
| | | > and lately to the network traffic shaping [1] which is very closely
| | | > related.
| | | > A reason of concern is the current design of network qos table[2].
| | | > 
| | | > First issue is the one related to the attributes associated to the
| | | > traffic
| | | > shaping (either inbound
| | | > or outbound), I got the chance to talk with Michal (a libvirt developer
| | | > in
| | | > Brno) which confirmed me
| | | > that the only compulsory attribute is average both burst and peak are
| | | > optional, also he told me that
| | | > libvirt doesn't provide any default values in case those are missing
| | | > ones.
| | | > Looking at missingValue()
| | | > method in [3] seems that all 3 values are compulsory.
| | | 
| | | By not defining the other two values, we actually leave the decision to
| | | libvirt. that means that the different libvirt releases
| | | may take different decision. when the user is setting a specific QoS for
| | | his
| | | network, he expect to see the same behavior over
| | | all of the VNICs using that QoS (even if they are running on different
| | | libvirt versions).
| | 
| | I will let Michal answer to this specific concern, I'm not fully convinced
| | that libvirt might place default values for unspecified attributes in the
| | future.
| | 
| 
| Giuseppe, you need to remember that a value may not necessarily be a number.
| It can also be a formula which will behave differently on overutilized VS
| underutilized hosts. Either way, undefined means exactly that. As a concept
| SLA cannot assume it, or we're loosing the upper bound capabilities.

Hi Doron, thanks for the explanation I wasn't aware of this concern.

| So for this reasoning we will start with as stable implementation as
| possible.
| Going forwards we may re-visit based on users feedback.

Ok, I'm going to update my proposal to conform with this choice.
Thanks for the feedback!

Cheers, Giuseppe

| 
| |  setting all three values in the engine
| | | allows us to force this unity. I will, however, add some default
| | | relations
| | | to
| | | the UI. so that when a user is setting the Average
| | | value, the Peak and Burst values will be automatically derived (but could
| | | be
| | | edited, of course).
| | | 
| | | > 
| | | > Second issue is mostly related to the decision of creating a single
| | | > table
| | | > with traffic shaping
| | | > for both incoming and outgoing traffic (in table defined respectively
| | | > as
| | | > inbound and outbound).
| | | > Incoming and outgoing traffic are independent and practically the same.
| | | > If
| | | > a
| | | > network admin defines
| | | > only incoming traffic, outgoing traffic attributes are nulls.
| | | > 
| | | > An alternative approach that we discussed is the following one: a table
| | | > named
| | | > simply qos
| | | > or if you prefer qos_profile with the three attributes average (not
| | | > null),
| | | > burst and peak and an id.
| | | > In this case after the user creates a profile, that one can be
| | | > associated,
| | | > as
| | | > you defined in your spec,
| | | > to a vnic (and in the future to a network). I'm not sure if we need a
| | | > different attribute
| | | > to specify for convenience the traffic at which the qos profile is
| | | > applied
| | | > (incoming/inbound, ougoing/outbound).
| | | 
| | | As for the difference between inbound and outbound, this is one of the
| | | most
| | | common use cases, i believe both your home and office
| | | networks have different inbound and outbound limits.
| | | As for the single table. first, in the future we plan on adding another
| | | attribute, "floor". which apply only to outbound.
| | | second, I don't really see in what way this is better than the current
| | | design
| | 
| | For how you've conceived the traffic shaping, which means having the user
| | define all values and traffic type, my proposal is no better than yours
| | but I was looking from a different angle.
| | 
| | | - and so I don't see why we should rewrite this
| | | feature from scratch one day before feature freeze.
| | 
| | There's no need to do that, right now, as said previously.
| | 
| | Thanks Giuseppe
| | 
| | | 
| | | > 
| | | > Cheers, Giuseppe
| | | > 
| | | > 
| | | > [0]http://www.ovirt.org/Features/Network_QoS
| | | > [1]http://www.ovirt.org/Features/Network_traffic_shaping
| | | > [2]http://gerrit.ovirt.org/#/c/16294/8/packaging/dbscripts/upgrade/03_03_0400_add_network_qos_tabel.sql
| | | > [3]http://gerrit.ovirt.org/#/c/16294/8/backend/manager/modules/bll/src/main/java/org/ovirt/engine/core/bll/qos/NetworkQoSCommandBase.java
| | | > 
| | | 
| | | thanks again,
| | | 
| | | Ofri
| | | 
| | 
| 