Network traffic shaping.

[Giuseppe Vallarelli]

----- Original Message -----
| From: "Doron Fediuck" <dfediuck at redhat.com>
| To: "Moti Asayag" <masayag at redhat.com>
| Cc: "Giuseppe Vallarelli" <gvallare at redhat.com>, arch at ovirt.org
| Sent: Sunday, July 21, 2013 10:09:01 AM
| Subject: Re: Network traffic shaping.
| 
| 
| 
| ----- Original Message -----
| | From: "Moti Asayag" <masayag at redhat.com>
| | To: "Giuseppe Vallarelli" <gvallare at redhat.com>
| | Cc: arch at ovirt.org
| | Sent: Friday, July 19, 2013 6:07:35 PM
| | Subject: Re: Network traffic shaping.
| | 
| | Hi,
| | 
| | According to the 'Detailed description' section in the wiki, it is stated
| | that the
| | admin may override the traffic shaping of the network on the data-center
| | level with
| | a specific one per host.
| | 
| | Is there a need to persist this configuration on the engine side and to
| | present it
| | to the user or we just passing these settings to the host while configuring
| | the
| | network on the host and abandoning them afterwards? Meaning, VDSM will
| | report
| | the QoS per
| | host's network and it will be presented to the user. But the actual values
| | that
| | were used to set these network QoS won't be persistent on the engine side?
| | 
| | The answer to the above has further implication on the design on engine
| | side,
| | therefore before starting futile discussion, is there such a requirement ?
| | 
| | ----- Original Message -----
| | > From: "Giuseppe Vallarelli" <gvallare at redhat.com>
| | > To: arch at ovirt.org
| | > Sent: Monday, July 8, 2013 1:45:41 PM
| | > Subject: Network traffic shaping.
| | > 
| | > Hi everybody, I'm working to implement traffic shaping at the network
| | > level
| | > [1].
| | > This feature is composed by two distinct parts: definition of traffic
| | > shaping
| | > for a logical network entity and optional redefinition of traffic shaping
| | > when
| | > the user is doing a Setup Host Networks task. Initial focus will be on
| | > first
| | > part. There are some points of contact with Network Qos [2] that's why I
| | > proposed
| | > to reuse some code backend side.
| | > 
| | > Cheers, Giuseppe
| | > 
| | > [1] http://www.ovirt.org/Features/Network_traffic_shaping
| | > [2] http://www.ovirt.org/Features/Network_QoS
| 
| Hi guys,
| Adding my comments to Moti's;
| 
| First of all Giuseppe, looks like a good start for a much needed
| functionality in oVirt.
| So thumbs' up on driving it forward and having this discussion in place ;)
| Somehow, your writing was taken out of context, so I think we should
| clarify the concepts to begin with;

Hi Doron,

| Host-level traffic shaping handles one aspect in the domain of QoS. For
| 3.3 we're already planning VM-level networking QoS and your feature is
| completing it.
| Network traffic shaping is one implementation libvirt chose, in order
| to provide quality of service at host level. Look for "quality of service"
| in [1]. But we should also remember that it may have additional
| implementations
| which goes all the way to the network device, as we will need to handle in
| provided networks.

All right.

| 
| So for completeness and clarification we should align host-level network QoS
| with VM-level network QoS. Let's start with renaming the feature from it's
| implementation to what it should provide: host network QoS. Ofri may assist
| you with renaming current pages as needed to improve things. This may also
| help me find the detailed description Moti was referring to.

Ok I agree on the naming issue, I wanted to get Network QoS (still not the
best name) but that was already used. Host network QoS sounds good to me.

| As a next step we should verify there are no conflicts in functionality
| and UI in both levels. Implementation wise, I like your re-use attempts,
| and I'd suggest revisiting the UI part based on network profiles. Network
| profiles are consumers for network QoS entities just as logical network is a
| consumer of network QoS entities. IIUC, you should be using the QoS left tab
| as depicted in [2] in the new/edit logical network dialog.

For your UI concern, the actual mockups are rough sketches it's probably
going to look different. I agree with you on the need of having a possible
uniform UI look'n'feel. A possible idea for future releases would be to
have a sort of unified QoS dashboard where the admin can have an overall
picture of the defined QoS at multiple levels.

| Going forward we'll have to close the gaps of the API for both levels,
| and make sure these QoS settings are managed properly as a policy and
| delivered to the host, where it will be enforced by MoM.

Ok, thanks for the feedback,
Giuseppe

| 
| Doron
| 
| [1] http://libvirt.org/formatnetwork.html
| [2] http://www.ovirt.org/File:New_netwrok_profiles.png
| 
| 
|