network and vnic qos

Sun Jul 14 08:36:45 UTC 2013

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

 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
| 