Network traffic shaping.

Giuseppe Vallarelli gvallare at redhat.com
Wed Jul 10 12:03:20 UTC 2013


----- Original Message -----
| From: "Moti Asayag" <masayag at redhat.com>
| To: "Giuseppe Vallarelli" <gvallare at redhat.com>
| Cc: arch at ovirt.org
| Sent: Wednesday, July 10, 2013 11:57:56 AM
| Subject: Re: Network traffic shaping.
| 
| Hi Giuseppe,
| 
| I'm in favour of reusing the entities which represent the network QoS for a
| network
| interface. However I'd store the vnic network QoS and host network QoS
| entries in
| different tables, else we miss the distinguish between network QoS designed
| for VMs
| to these used for hosts.

I would rather not duplicate or having two different tables which in practice
are almost the same. I would add a new attribute like qos_type with 2 possible
values for now: vnic and network to distinguish between the 2. What do you think?

| Which leads to the next issue: The network traffic shaping will follow the
| Vnic Network QoS [1],
| therefore the Vnic network QoS should be have an upper limit set by the
| host's VM network QoS for
| the same VM network. What would be the behaviour in case the total average
| bit-rate of the VMs
| exceeds the host network bit-rate ?

The underlying implementation of libvirt works in this way:
if you shape the network bandwidth and it's tighter than the vnic
shaped bandwidth than you will not have a bandwidth throughput of vnic
higher than the one defined by the shaped network. The network
bandwidth act as a constraint here. If the user gets the bandwidth
values wrong the traffic can't go faster of what the underlying
technology provides.

Now given this premise we can have 2 different scenarios:

Scenario 1:

User defines network QoS and vnics QoS whose values (vnic)
for average, burst and peak should be lesser or equal
to the ones defined in the network.

Scenario 2:

User only defines vnics QoS which is in practice still constrained by
the underlying nic's capacity, no matter of user's wishes.

| Is there any limit for the peak or burst ? and if there is, are they differ
| between the host network
| QoS to the vnic QoS?

There is no limit for peak and burst or default value that libvirt provides.
I need to add that the only compulsory attribute for bandwidth definition is
only average, burst and peak are optional values as well as incoming and
outgoing traffic can be shaped independently (I would use incoming and outgoing
respectively for inbound and outbound, I think they're better terms for labels
in the mockups)

| Regarding the 'New Logical Network' dialog, I'd suggest to add the Network
| QoS as a left tab, rather
| than having it on the main dialog. See [2] a mock-up of the new dialog
| shortly which includes the
| vnic profile left-tab, and also the QoS left-tab.

I agree on having a unified UI. Not much with the multiple tabs.
I consider the multiple tabs approach valid when they're related
to different concepts, where each concept is independent.
Which is not valid in this case. I would expect to have a single
unified tab for QoS which includes both network and vnics.

| 
| In addition, should there be a new 'QoS' sub-tab for the networks tab ?

See previous answer. Perhaps it might have more sense to have a vnic profiles
as a sub-tab due to the previous considerations.

Cheers, Giuseppe

| 
| 
| [1] http://www.ovirt.org/Features/Network_QoS
| [2] http://www.ovirt.org/File:New_netwrok_profiles.png
| 
| Moti
| 
| ----- 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
| > _______________________________________________
| > Arch mailing list
| > Arch at ovirt.org
| > http://lists.ovirt.org/mailman/listinfo/arch
| > 
| 



More information about the Arch mailing list