network and vnic qos

[Ofri Masad]

Hi Giuseppe,

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.

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). 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 - and so I don't see why we should rewrite this 
feature from scratch one day before feature freeze.     

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