network and vnic qos

Sun Jul 14 09:16:02 UTC 2013

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

|  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
| | 
| 